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Analysts:  A  type  of  stakeholder.  Individuals  of  groups  that  evaluate  the  effective 
needs  which  assisted  in  determining  the  projected  performance  of  various 
system  alternatives  to  determine  the  most  efficient  and  effective  alternative. 

Area  of  Operations  (AO):  An  operational  area  defined  by  the  joint  force 
commander  for  land  and  naval  forces.  Areas  of  operations  do  not  typically 
encompass  the  entire  operational  area  of  the  joint  force  commander,  but  should 
be  large  enough  for  component  commanders  to  accomplish  their  missions  and 
protect  their  forces. 

Advanced  Field  Artillery  Tactical  Data  System  (AFATDS):  AFATDS  is  an 
integrated  fire  support  system  used  by  Army  and  Marine  Corps.  It  processes  fire 
mission  and  other  related  information  to  coordinate  the  use  of  fire  support  assets, 
including  mortars,  field  artillery,  cannon,  missile,  attack  helicopters,  air  support, 
and  limited  naval  gunfire. 

Advanced  Tomahawk  Weapons  Control  System  (ATWCS):  ATWCS  is  an 
upgrade  to  the  initial  Tomahawk  system.  The  ATWCS  improvements  include 
hardware,  software,  and  firmware  modifications.  The  added  capabilities  include: 
contingency-strike  operations  planning,  embedded  training  at  all  levels,  and  a 
simplified  man-machine  interface.  It  is  used  for  the  planning,  execution,  and 
launch  of  the  Tomahawk  missile  aboard  naval  ships  and  submarines. 

Airborne  Warning  and  Control  System  (AWACS):  AWACS  provides 
all-weather  surveillance,  command,  control  and  communications  needed  by 
commanders  of  U.S.  and  NATO  air  defense  forces. 

Applique  System:  The  applique  system  is  an  experimental  battlefield 
digitization  computer  system  consisting  of  four  basic  versions  of  hardware 
installed  on  vehicles  and  used  by  individual  soldiers,  connected  by  a  radio 
system. 

Automated  Deep  Operations  Coordination  System  (ADOCS):  The 

Automated  Deep  Operations  Coordination  System  (ADOCS)  developed  by 
General  Dynamics  is  a  joint  mission  management  software  application.  It 
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provides  a  suite  of  tools  and  interfaces  for  horizontal  and  vertical  coordination 
across  battlespace  functional  areas. 

Clients:  Agencies  or  groups  of  people  that  will  have  substantial  input  as  to  the 
development  of  the  solution  set  or  system. 

Close  Air  Support  (CAS):  Air  action  by  fixed-  and  rotary-wing  aircraft  against 
hostile  targets  which  are  in  close  proximity  to  friendly  forces  and  which  require 
detailed  integration  of  each  air  mission  with  the  fire  and  movement  of 
those  forces. 

Danger  Close:  In  close  air  support,  artillery,  mortar,  and  naval  gunfire  support 
fires,  it  is  the  term  included  in  the  method  of  engagement  segment  of  a  call  for 
fire  which  indicates  that  friendly  forces  are  within  close  proximity  of  the  target. 
The  close  proximity  distance  is  determined  by  the  weapon  and  munition  fired. 
Command  Post  of  the  Future  (CPOF):  A  system  currently  deployed  at  the 
division  level.  Enables  division  and  brigade  commanders  to  discuss  and 
collaborate  when  processing  information,  share  ideas,  and  attend  virtual 
meetings  without  assembling  at  one  place. 

Decision  Makers:  A  type  of  stakeholder.  Personnel  or  organizations  who  have 
the  authority  to  make  impacting  and  final  project  decisions. 

Electronic  Warfare  (EW):  Any  military  action  involving  the  use  of 

electromagnetic  and  directed  energy  to  control  the  electromagnetic  spectrum  or 
to  attack  the  enemy. 

Enhanced  Position  Location  and  Reporting  System  (EPLRS):  A  system  that 
provides  secure,  jam-resistant,  near  real-time  data  communications  support  for 
the  five  Battlefield  Functional  Areas  of  the  Army  Tactical  Command  and  Control 
System  (ATCCS). 

Fire  Support  Coordination:  The  planning  and  executing  of  fire  so  that  targets 
are  adequately  covered  by  a  suitable  weapon  or  group  of  weapons. 

Fire  Support  Coordination  Center  (FSCC):  A  single  location  in  which  are 
centralized  communications  facilities  and  personnel  incident  to  the  coordination 
of  all  forms  of  fire  support. 
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Fires:  The  effects  of  lethal  or  nonlethal  weapons. 

Force  XXI  Battle  Command,  Brigade  and  Below  (FBCB2):  The  FBCB2 
consists  of  Applique  hardware,  software  and  EBC  Software  integrated  into  the 
various  platforms  at  brigade  and  below,  as  well  as  appropriate  Division  and 
Corps  slices  necessary  to  support  brigade  operations.  It  interconnects  platforms 
through  a  communications  infrastructure  called  the  Tactical  Internet  consisting  of 
existing  EPLRS  and  SINCGARS  nets  to  pass  Situation  Awareness  data  and 
conduct  Command  and  Control.  Primary  functions  are  to  send  out  and  receive 
automatic  position  location  reports,  and  to  send  and  receive  command  and 
control  message  traffic  and  graphics  for  display. 

Global  Command  and  Control  System  (GCCS):  The  Global  Command  and 
Control  System  (GCCS)  is  an  automated  information  system  designed  to  support 
deliberate  and  crisis  planning  with  the  use  of  an  integrated  set  of  analytic  tools 
and  the  flexible  data  transfer  capabilities. 

Global  Information  Grid  (GIG):  A  net-centric  system  operating  in  a  global 
context  to  provide  processing,  storage,  management,  and  transport  of 
information  to  support  all  Department  of  Defense  (DoD),  national  security,  and 
related  intelligence  community  missions  and  functions-strategic,  operational, 
tactical,  and  business-in  war,  in  crisis,  and  in  peace. 

Joint:  Activities,  operations,  organizations,  etc.,  in  which  elements  of  two  or 
more  Military  Departments  participate. 

Joint  Battle  Management  Command  and  Control  (JBMC2):  JBMC2  consists 
of  the  processes,  architectures,  systems,  standards,  and  command-  and-control 
operational  concepts  employed  by  the  joint  force  commander.  The  joint  force 
commander  executes  joint  operations  by  employing  the  entire  array  of  JBMC2 
capabilities  during  the  planning,  coordinating,  directing,  controlling,  and 
assessing  of  joint  force  operations  from  interface  with  the  strategic  level  through 
the  tactical  level. 

Joint  Fires  (JF):  Fires  produced  during  the  employment  of  forces  from  two  or 
more  components  in  coordinated  action  toward  a  common  objective. 
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Joint  Fire  Support  (JFS):  Joint  fires  that  assist  land,  maritime,  amphibious,  and 
special  operations  forces  to  move,  maneuver,  and  control  territory,  populations, 
and  key  waters. 

Joint  Force  Commander  (JFC):  A  general  term  applied  to  a  combatant 
commander,  subunified  commander,  or  joint  task  force  commander  authorized  to 
exercise  combatant  command  (command  authority)  or  operational  control  over  a 
joint  force. 

Joint  Operations:  A  general  term  to  describe  military  actions  conducted  by  joint 
forces  or  by  Service  forces  in  relationships  (e.g.,  support,  coordinating  authority) 
which,  of  themselves,  do  not  create  joint  forces. 

Joint  Surveillance,  Target  Attack  Radar  System  (JSTARS):  Long-range, 
air-to-ground  surveillance  system  designed  to  locate,  classify  and  track  ground 
targets  in  all  weather  conditions. 

Joint  Targeting  Coordination  Board  (JTCB):  A  group  formed  by  the  Joint 
Force  Commander  to  accomplish  broad  targeting  oversight  functions  that  may 
include  but  are  not  limited  to  coordinating  targeting  information,  providing 
targeting  guidance  and  priorities,  and  preparing  and/or  refining  joint  target  lists. 
The  board  is  normally  comprised  of  representatives  from  the  joint  force  staff,  all 
components,  and  if  required,  component  subordinate  units. 

Naval  Fires  Control  System  (MFCS):  MFCS  is  a  battle  management  system 
that  enables  for  surface  land  attack  in  net-centric  warfare.  MFCS  supports 
mission  planning  for  5762  -  Advanced  Gun  System  and  Extended  Range  Guided 
Munitions  (ERGM). 

Rules  of  Engagement  (ROE):  Directives  issued  by  competent  military  authority 
which  delineate  the  circumstances  and  limitations  under  which  United  States 
forces  will  initiate  and/or  continue  combat  engagement  with  other  forces 
encountered. 

Single  Channel  Ground  and  Air  Radio  System  (SINCGARS):  SINCGARS  is  a 
family  of  VHF-FM  combat  net  radios  which  provides  the  primary  means  of 
command  and  control  for  Infantry,  Armor  and  Artillery  Units.  SINCGARS  is 
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designed  on  a  modular  basis  to  achieve  maximum  commonality  among  the 
various  ground  and  airborne  system  configurations. 

Sponsors:  A  type  of  stakeholder.  Offices  or  groups  of  people  that  provide 
financial  support,  which  may  include  technical  support  or  support  in  the  form  of 
special  studies  or  specialized  information. 

Stakeholders:  Stakeholders  are  a  group  of  people  (users,  owners, 

manufacturers,  maintainers,  trainers,  etc.)  for  whom  a  system  is  being  built. 
Target  Location,  Designation  and  Handoff  System  (TLDHS):  A  modular, 
man-portable  equipment  suite  that  will  provide  the  ability  to  quickly  acquire 
targets  in  day,  night,  and  near-all-weather  visibility  conditions.  Operators  will  be 
able  to  accurately  determine  their  own  location  as  well  as  that  of  their  targets, 
digitally  transmit  (hand-off)  data  to  supporting  arms  elements,  and  designate 
targets  for  laser-seeking  Precision  Guided  Munitions  (PGM)  and  Laser  Spot 
Trackers  (LST). 

Theater  Air  Control  System  (TAGS):  The  Theater  Air  Control  System  (TAGS) 
provides  the  Air  Force  Component  Commander  (AFCC)  and  the  Joint  Forces  Air 
Component  Commander  (JFACC)  the  capability  to  plan  and  conduct  theater  air 
operations,  including  joint  US  operations  and  combined  operations  with  allied 
forces.  The  TAGS  supports  the  Air  Force  doctrine  of  centralized  control  and 
decentralized  execution  of  theater  air  support  assets. 

Theater  Battle  Management  Core  System  (TBMCS):  Provides  the  Combat  Air 
Forces  (CAF)  and  the  Joint/Combined  Forces  with  an  automated  and  integrated 
capability  to  plan  and  execute  the  air  battle  plan  for  operations  and  intelligence 
personnel  at  the  force  and  unit  levels. 

Troops  in  Contact  (TIC):  A  close  air  support  situation  where  the  friendly  troops 
are  within  1  kilometer  of  the  intended  targets  unless  the  ground  commander 
determines  otherwise.  JTACS  and  aircrews  must  carefully  weigh  the  choice  of 
ordinance  and  delivery  profile  in  relation  to  the  risk  of  fratricide  in  a  TIC  situation. 
Users:  A  type  of  stakeholder.  Agencies  or  groups  of  people  that  will  actually 
use  the  system  that  is  developed. 
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EXECUTIVE  SUMMARY 


The  Joint  Fire  Support  in  2020  project  represents  a  cooperative  research 
study  involving  the  Naval  Postgraduate  School  (NPS)  Systems  Engineering  and 
Analysis  (SEA)  curriculum,  other  student  groups  on  campus,  and  more  than  10 
NPS  faculty  members.  The  impetus  for  this  undertaking  was  a  request  by  US 
Joint  Forces  Command  (JFCOM)  to  both  NPS  and  the  Air  Force  Institute  of 
Technology  (AFIT)  to  study  and  analyze  possible  joint  war  fighting 
improvements.  Analysis  was  performed  in  one  of  the  many  study  areas 
described  in  the  Joint  Battle  Management  Command  and  Control  (JBMC2) 
Roadmap  published  by  JFCOM  in  2005.  The  seven  SEA-10  students  in  the  Joint 
Fires  Support  Project  Team  utilized  a  tailored  Systems  Engineering  Design 
Process  (SEDP),  an  iterative  procedure  that  facilitated  a  methodical  approach  to 
solve  the  design  problem,  composed  of  three  phases:  Problem  Definition, 
Design  and  Analysis,  and  Decision  Making. 

During  the  Problem  Definition  phase,  the  Joint  Fires  Team  conducted  an 
extensive  analysis  of  existing  and  proposed  fire  support  systems.  Stakeholders 
were  identified  and  interviewed  and  an  Effective  Need  was  developed.  This 
Effective  Need  was  to  define  an  operationally  feasible  Joint  Fires  request, 
coordination,  and  tasking  architecture  to  provide  rapid  battlefield  effects  to  the 
Commander.  This  type  of  request  system  would  allow  for  fire  support  that  is 
effects-based  rather  than  fire  support  that  is  service-centric. 

Metrics  were  identified  to  evaluate  the  performance  of  the  competing 
alternatives  ability  to  meet  the  objectives  of  the  Effective  Needs  statement. 
These  metrics  were:  average  processing  time  for  a  request  to  be  serviced,  the 
pairing  effects  ratio  of  tasked  providers,  and  the  number  of  systems,  decision 
points,  steps,  and  process  gaps  involved  in  the  request-to-task  process. 

Alternative  system  architectures  were  developed  that  would  achieve  the 
objectives  presented  in  the  Effective  Need.  After  considering  current  program 
development  and  realistic  technological  advances,  three  distinct  alternatives 
were  evaluated  as  feasible  architectures  for  a  future  joint  fire  support  system. 
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The  Status  Quo  Plus  alternative  is  an  expansion  of  the  current  “as  is”  fire 
support  systems.  It  is  based  on  the  growth  path  of  existing  programs  of  record 
and  published  fire  support  related  roadmaps.  This  system  will  benefit  from 
improvements  in  both  capabilities  and  materiel  during  this  timeframe,  but  it 
retains  most  of  the  current  fire  support  system  organizations  and  processes. 

The  Centralized  Joint  Fires  Support  Network  (CJFSN)  capitalizes  on  the 
DoD  transformation  to  a  force  with  improved  communications  connectivity.  A 
defining  component  of  this  alternative  is  the  Joint  Fire  Cell.  It  is  the  key  to 
horizontal  and  vertical  consolidation  of  functionally-equivalent  organizations.  The 
Joint  Fires  Cell  will  receive,  acknowledge,  process,  pair,  and  task  joint  fire 
requests  to  a  provider.  This  will  enable  a  request  for  fire  to  be  sent  to  a  single 
decision-making  organization  that  will  collectively  choose  and  task  the  best  joint 
asset  available.  Overall  processing,  pairing,  and  decision  making  is  expected  to 
be  faster  because  the  JFS  resource  owners  are  organizationally  intertwined  and 
combined. 

The  Distributed  Joint  Fires  Support  Network  (DJFSN)  represents  a  fully 
networked  force,  enabled  to  share  fire  requests  and  tasking  information.  This 
alternative  assumes  common,  fully  interoperable  Command  and  Control  (C2) 
data  at  lower  echelon  units  including  battalions,  ships,  and  aircraft.  In  this 
alternative,  the  fire  support  requests  are  sent  to  a  fire  support  database  via  the 
Global  Information  Grid  (GIG).  All  participating  fire  support  providers  evaluate 
engagement  capabilities  with  automated  algorithms.  Commonality  of  Command 
Control,  Communication,  and  Intelligence  (C3I)  and  automated  pairing  algorithms 
will  allow  for  selection  and  tasking  of  an  agreed  “preferred  shooter.”  The  Joint 
Force  Commander  exercises  oversight  and  command  by  negation  as  a 
participating  unit  throughout  the  process. 

Qualitative  and  quantitative  modeling  and  simulation  were  used  to  assess 
the  complexity  and  performance  of  these  alternatives.  Qverall  modeling 
performance  convinced  the  Project  Team  to  rank  the  DJFSN  as  the  best  system 
and  CJFSN  as  better  than  Status  Quo  Plus. 


A  subjective  assessment  of  the  implementation  challenges  and 
operational  risks  of  the  alternatives  with  respect  to  expected  missions  was 
conducted.  The  team  rated  each  alternative’s  overall  risk  by  assessing  the 
scope  of  changes  required  to  implement  while  simultaneously  maintaining 
current  operations.  The  Status  Quo  Plus  was  estimated  to  have  the  lowest  risk, 
the  CJFSN  moderate  risk,  and  the  DJFSN  was  estimated  to  present  the  highest 
implementation  risk. 

Overall,  the  DJFSN  represents  the  alternative  with  the  greatest  risk  to 
implement  but  most  opportunity  for  operational  benefit.  Because  of  the  expected 
performance,  the  DJFSN  was  chosen  as  the  preferred  architecture.  While  Status 
Quo  Plus  has  little  risk  to  implementation,  it  also  has  low  expected  benefit. 

The  path  to  implementing  the  DJFSN  can  be  achieved  at  a  much  lower 
risk  to  day-to-day  operations  by  transitioning  to  a  CJFSN  first.  The  CJFSN  is  the 
logical  first  evolutionary  step  towards  the  DJFSN.  This  “build  a  little,  test  a  little” 
approach  will  allow  gradual  development  of  the  required  doctrinal,  organizational, 
and  procedural  changes. 

To  implement  the  CJFSN  alternative,  the  team  recommends  several 
changes  be  made  immediately  to  the  realm  of  Joint  Fire  Support.  The 
functionally  equivalent  organizations  should  be  consolidated  in  order  to 
overcome  the  cumbersome  C2  process  of  the  planned  joint  fire  support 
organization.  The  joint  responsibilities,  and  explicit  command  and  decision 
making  relationships,  should  be  clearly  established.  The  tactics,  training,  and 
procedures  for  immediate  unplanned  fire  support  should  be  clarified  and 
integrated  into  widely-disseminated  Joint  Tactical  Doctrine  and  Procedures. 

Tactical  decision  aides  should  be  developed  in  support  of  capability-based 
operations.  The  Joint  Fires  Cell  processing  time  and  efficiency  would  benefit 
from  these  automated  tactical  decision  aides.  Additionally,  they  will  form  the 
basis  for  fully  automated  prioritization,  pairing,  and  deconfliction  algorithms 
required  by  the  DJFSN  alternative. 


XXIX 


The  DJFSN  requires  a  fully  joint  common  operational  picture.  To  achieve 
commonality  and  timeliness  of  the  information,  the  team  recommends  a  single 
Joint  PEO  to  provide  oversight  in  the  design,  acquisition,  and  fielding  of  a 
common  interoperable  C3I  system  to  enable  distributed  networked  decision 
making. 
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1.0  INTRODUCTION 


1.1  PURPOSE 

The  purpose  of  this  report  is  to  document  and  detail  the  conduct  and 
results  of  the  Wayne  E.  Meyer  Institute’s  cross-campus  study  entitled  Joint  Fire 
Support  in  2020:  Development  of  a  Future  Joint  Fires  Systems  Architecture  for 
Immediate,  Unplanned  Targets.  Conducted  at  the  Naval  Postgraduate  School 
(NPS)  from  July  through  December  2006,  this  study  was  led  and  managed  by 
students  in  the  Systems  Engineering  and  Analysis  (SEA)  curriculum  and  includes 
the  academic  efforts  and  intellectual  contributions  of  numerous  members  of  the 
NPS  student  and  faculty  community.  The  purpose  of  the  study  was  to  provide 
insight  into  the  theory  and  execution  of  Joint  Fire  Support  in  order  to  improve  its 
application  in  future  conflicts.  This  project  fulfills  a  major  portion  of  the  SEA 
student’s  academic  requirements  to  be  awarded  the  Masters  of  Science  degree 
in  Systems  Engineering  and  Analysis. 

1.2  TASKING 

Working  with  their  project  advisors,  students  in  SEA  Cohort  Ten  (SEA-10), 
were  tasked  to  lead  a  six-month  systems  engineering  and  analysis  study  to 
investigate  alternative  architectures  to  improve  the  US  Department  of  Defense’s 
(DoD)  execution  of  Joint  Fire  Support  (JFS)  in  2020.  Stemming  from  background 
issued  in  the  Joint  Battle  Management  Command  and  Control  (JBMC2) 
Roadmap,  study  and  analysis  was  conducted  of  JFS  concepts  as  they  pertain  to 
the  current  and  planned  DoD  doctrinal,  organizational,  and  equipment  constructs. 
The  broad  tasking  was  to  “design  a  conceptual  system  of  systems  to  enable 
future  Joint  Close  Air  Support,  Time  Sensitive  Targeting,  and  Joint  Fires 
missions.’’^  The  scope  of  the  tasking  allowed  for  exploration  of  a  wide  variety  of 
topics  to  determine  an  area  of  study  with  potential  for  significant  impact  or 

^  Frank.  E.  Shoup,  “SEA-10  Capstone  Project  Objectives,”  Naval  Postgraduate  School, 
Monterey,  CA,  3  April  2006. 
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insight.  Focus  areas  identified  in  the  tasking  were:  to  identify  capability  gaps; 
options  for  the  integration  of  different  service  air,  surface,  and  subsurface  fires; 
and  to  address  Concepts  of  Operation  (CONORS),  systems  capabilities,  and 
training  issues  as  part  of  a  system  of  systems  for  the  missions  and  capability 
gaps  identified.^ 

The  diverse  professional  makeup  of  the  SEA-10  Project  Team  was 
significant  to  the  selection  of  Joint  Fires  Support  as  the  area  of  study.  The  team 
consisted  of  four  US  Navy  officers,  two  US  Air  Force  officers,  and  one  US  Army 
officer.  Each  member  of  this  unique  team  brought  with  them  extensive 
operational  experience:  in  USN  and  USAF  tactical  aviation,  USN  surface  and 
undersea  warfare,  USN  and  USA  communications  and  networking  operations, 
and  USAF  acquisition  and  aircraft  maintenance  projects. 

In  addition  to  conducting  the  bulk  of  the  project  work,  the  team  led  and 
managed  the  effort,  supported  by  other  student  and  faculty  teams  from  across 
NPS.  Our  team  employed  the  project  management  tools  and  methodology 
studied  in  their  course  work  at  NPS. 

1.3  PROJECT  METHODOLOGY 

The  Project  Team  utilized  a  Systems  Engineering  Design  Process  (SEDP) 
that  fused  design  and  methodology  elements  from  several  recognized  System 
Engineering  experts,  including  Buede,  Blanchard,  Fabrycky,  and  Paulo. ^  The 
SEDP  is  an  iterative  process  that  facilitates  a  methodical  approach  to  a  design 
problem.  A  tailored  SEDP  was  utilized  in  the  Joint  Fires  project  that  was 
composed  of  three  phases:  Problem  Definition,  Design  and  Analysis,  and 
Decision  Making. 

The  products  of  each  of  the  SEDP  phases  combined  to  form  an  overall 
systems  architecture  for  the  project.  The  systems  architecture  used  follows  the 


^  F.E.  Shoup,  “SEA-10  Capstone  Project  Objectives,”  Naval  Postgraduate  School,  Monterey, 
CA,  3  April  2006. 

^  E.P.  Paulo,  “Systems  Engineering  and  Architecture,”  (Class  Notes),  Naval  Postgraduate 
School,  Monterey,  CA,  2006. 
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model  attributed  to  Buede.'^  He  describes  the  overall  systems  architecture  as 
being  composed  of  a  functional,  physical,  and  operational  architecture. 
Throughout  the  process  of  developing  and  assessing  the  proposed  system  of 
systems,  the  team  considered  each  of  the  three  architectures  in  the  framework  of 
the  DOTMLPF  model  (Doctrine,  Organization,  Tactics  and  Training,  Materiel, 
Leadership  and  Education,  Personnel  and  Facilities). 

The  purpose  of  a  functional  architecture  is  to  provide  a  framework  for  all  of 
the  interactions  within  a  system  and  within  the  environment  in  which  the  system 
will  exist.  It  identifies  the  connections  between  all  of  the  functional  parts  of  the 
system.  According  to  Buede, 

The  functional  architecture  defines  what  the  system  must  do,  that 
is,  the  system’s  functions  and  the  data  that  flows  between  those 
functions.  The  functional  architecture  of  a  system  contains  a 
hierarchical  model  of  the  functions  performed  by  the  system,... a 
data  model  of  the  system’s  items;  and  a  tracing  of  input/output 
requirements  to  both  the  system’s  functions  and  items.^ 

A  physical  architecture  defines  the  resources  and  components  which 
comprise  the  system  identified  in  the  functional  architecture.  These  resources 
are  identified  in  a  “top-down”  manner  that  creates  a  hierarchical  architecture. 
Buede  states. 

The  physical  architecture  of  a  system  is  a  hierarchical  description  of 
the  resources  that  comprise  the  system.  This  hierarchy  begins  with 
the  system  and  the  system’s  top-level  components  and  progresses 
down  to  the  configuration  items  (CIs)  that  comprise  each 
intermediate  component.  The  CIs  can  be  hardware  or  software 
elements  or  combinations  of  hardware  and  software,  people, 
facilities,  procedures,  and  document’s.  The  physical  architecture 
provides  resources  for  every  function  identified  in  the  functional 
architecture.® 

The  last  architecture  to  be  developed  is  the  operational  architecture.  The 
operational  architecture  combines  the  elements  of  the  functional  and  physical 


D.M.  Buede,  The  Engineering  Design  of  Systems,  John  Wiley  &  Sons,  Inc.,  2000,  p.  175. 
^  Ibid. 

'^Ibid.,pp.  215-216. 
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architectures  to  completely  describe  the  system  design.  This  architecture  is 

specific  enough  to  begin  modeling  and  conducting  analysis  of  alternatives. 

Buede  describes  the  operational  architecture  as  follows: 

The  development  process  for  the  operational  architecture  is  the 
activity  during  which  the  entire  design  comes  together.  The 
operational  architecture  integrates  the  requirements  decomposition 
with  the  functional  and  physical  architectures.^ 


The  process  of  developing  these  architectures,  described  in  detail  in 
Chapters  2,  3,  and  4,  enabled  us  to  propose  alternative  solutions  and  analyze 
them  during  the  Design  and  Analysis  Phase.  Several  alternative  system  designs 
were  assessed  and  comparisons  included  analysis  of  modeling  and  simulation 
results.  Details  of  this  process  and  the  modeling  performed  are  described  in 
Chapter  4  of  this  report.  Cost,  risk,  and  reliability  assessments  are  discussed  in 
Chapters  5  and  6.  The  Decision-Making  Phase  was  the  final  step  in  this  project, 
and  the  rationale  and  analysis  for  those  decisions  are  described  in  the  Chapter  7 
of  this  report. 

1 .4  JOINT  FIRES  EXPLORATION 

Joint  Fire  Support  (JFS)  can  be  most  simply  described  as  coordinated  fire 

support  from  more  than  one  service  component.  Because  of  the  challenges 

involved  in  coordination  between  services,  JFS  has  historically  been  an  area 

where  the  reality  of  joint  operations  performance  falls  short  of  expectations. 

According  to  the  Defense  Science  Board, 

To  take  advantage  of  the  full  potential  for  joint  fires  and  close  air 
support  in  a  future  characterized  by  non-linear  battlespace 
operations,  zero  tolerance  for  fratricide  and  collateral  damage  and 
emerging  expanded  capabilities  in  coordinate-seeking  weapons 
(CSW),  there  must  be  a  commensurate  improvement  in  the 


D.M.  Buede,  The  Engineering  Design  of  Systems,  John  Wiley  &  Sons,  Inc.,  2000, 
pp.  245-246. 
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approach  that  our  forces  employ  in  command  and  control  for  fires, 
both  within  the  Services  and  in  joint  fire  support  across  Services.® 

The  potential  benefits  of  truly  “joint”  fire  support  where  all  services  can  potentially 
interoperate  with  all  other  service  are  enticing.  By  applying  a  methodical  study 
process  based  on  a  top-down  view  of  this  area  of  opportunity,  the  Project  Team 
attempted  to  identify  areas  of  improvement  with  both  Materiel  and  non-Materiel 
solutions  in  the  context  of  the  DOTMLPF  concept. 

1 .5  CONCEPT  OF  OPERATIONS 

The  modern  battlefield  contains  a  wide  variety  of  weapon  systems,  each 
with  unique  capabilities,  limitations,  tactics,  and  technology.  Employing  these 
weapons,  and  their  associated  lethal  or  nonlethal  effects,  in  a  synchronized 
manner  to  achieve  a  desired  outcome  is  the  essence  of  fire  support.  The 
weapon  systems  that  will  be  used  to  affect  JFS  operate  from  different 
environments  (land,  air,  sea)  and  may  be  operated  by  different  service 
components.  The  mechanisms  by  which  a  commander  can  improve  the 
synergistic  effects  of  these  weapons  systems  can  be  anything  from  a  small 
organizational  structure  change  to  the  development  of  large,  complex  battle 
management  systems.  The  tactical  complexity  of  this  type  of  situation  has 
challenged  past  leaders  and  continues  to  challenge  current  efforts  to  deploy  a 
system  that  efficiently  utilizes  all  available  resources  on  the  battlefield. 

As  a  historical  reaction  to  this  complexity,  major  weapon  systems  and  the 
fire  support  they  provide  have  been  deployed  and  controlled  along  service  and 
functional  guidelines.  For  example,  the  methodology  and  routing  for  requesting 
artillery  support  is  completely  different  from  the  methodology  and  routing  for 
Close  Air  Support  (CAS)  requests.  In  a  similar  way,  although  the  methodologies 
for  requesting  US  Army  or  Marine  artillery  support  are  very  similar,  the  routings  of 
the  requests  are  through  different  channels.  Similar  distinctions  exist  for  naval 

®  Department  of  Defense,  “Report  of  the  Defense  Science  Board  Task  Force  on  Integrated 
Fire  Support  in  the  Battlespace,”  Office  of  the  Undersecretary  of  Defense  for  Acquisition, 
Technology,  and  Logistics,  October  2004,  p.  55. 
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fire  support  providers  and  close  air  support,  to  include  a  conspicuous  separation 
between  the  Navy/Marine  aviation  and  Air  Force  aviation  request  and  tasking 
systems.  Despite  the  differences  in  request  formats  and  methodologies,  the 
basic  target  information  is  all  essentially  identical  throughout  these  processes. 

These  organizational  or  functional  fire  support  request  “stovepipes”  were 
intended  to  simplify  the  problem  and  allow  for  relatively  efficient  movement  of 
requests  and  tasking  within  the  associated  systems,  but  they  inhibit  the 
movement  of  requests  and/or  tasking  across  these  stovepipes.  This  placed  the 
burden  for  selection  of  a  fire  support  asset  on  the  requesting  unit,  and  assumes 
the  unit  possesses  the  equipment,  training,  and  routing  knowledge  to  send  their 
request.  It  also  required  duplication  of  capabilities  between  stovepipes  in  order 
to  minimize  response  time  within  each  stovepipe. 

The  current  system  can  be  described  using  the  simplified  example  in  the 
graphical  depiction  shown  in  Figure  1.  A  forward  element,  represented  by  the 
figure  at  the  bottom  of  the  graphic,  has  identified  a  target  and  determined  that  fire 
support  is  required.  In  the  current  system,  that  forward  element  must  choose  a 
fire  support  provider  and  the  associated  functional  stovepipe  to  send  their  fire 
support  request  through.  In  this  example,  the  forward  element  is  capable  of 
sending  their  request  through  four  request  pathways:  Army  artillery.  Air  Force 
CAS,  Marine  CAS,  or  naval  gun  fire.  There  is  no  way  for  the  forward  element  to 
know  which  request  pathway  will  provide  the  most  effective  response,  in  terms  of 
both  response  time  and  response  effects.  If  a  request  is  vetted  through  a 
stovepipe  and  there  are  no  weapons  or  providers  available  to  service  the 
request,  the  forward  element  must  then  re-send  the  request  through  a  different 
stovepipe.  These  delays  and  repetitive  requests  add  delays  and  reduce  the 
effectiveness  of  the  response. 
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Figure  1:  Current  Fire  Support  Request  System  Stovepipes 


An  improved  concept  for  Joint  Fires  should  effectively  eliminate  these 
stovepipes  in  order  to  more  efficiently  use  the  wide  variety  of  systems  deployed 
on,  above,  or  near  the  battlefield.  The  conceptual  design  could  be  built  to 
efficiently  pass  requests  and  tasking  orders  across  these  functional  or  service- 
specific  stovepipes,  or  it  could  eliminate  the  stovepipes  altogether  and  route  all 
requests  and  tasking  orders  through  a  single  pathway  or  methodology.  A 
conceptual  system  that  strikes  a  balance  between  these  two  alternatives  may  be 
the  most  effective.  This  type  of  system  would  transition  those  requests  into  the 
appropriate  fire  support  provider  stovepipe  for  tasking  and  response.  In  much 
the  same  way  that  a  “911”  call  center  connects  callers  with  the  appropriate 
emergency  response  agency  (police,  fire,  ambulance),  this  conceptual  system 
could  allow  all  units  with  compatible  equipment  to  receive  any  of  the  available  fire 
support  from  any  available  providers.  Using  the  simplified  example  and  available 
fire  support  providers  shown  in  Figure  1,  the  same  forward  element  no  longer 
has  to  choose  the  functional  stovepipe  to  contact.  The  conceptual  system  shown 
in  Figure  2  allows  the  requesting  element  to  use  a  common  methodology  and 
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routing  to  send  a  request  for  fire  support.  This  request  is  then  tasked  to  the 
“best”  available  provider.  The  choice  of  which  provider  is  “best”  is  defined  by 
numerous  factors  including,  but  not  limited  to:  intent  of  the  request  and/or  the 
force  commander,  the  availability  of  the  weapon  systems,  the  degree  to  which 
the  weapons  are  capable  of  meeting  the  requested  effect,  and  the  characteristics 
of  the  target.  This  type  of  request  system  would  allow  for  fire  support  that  is 
effects-based  rather  than  fire  support  that  is  service-centric.  This  conceptual 
system  could  improve  the  efficiency  of  JFS;  and  when  combined  with  the 
improvements  in  weapon  lethality  and  precision,  it  could  affect  a  dramatic 
increase  in  JFS  effectiveness. 


"Best" 

Fire  Support 
Selection  . 


Tasking  Tasking 


Some  Considerations:  \ 
Commander's  Intent 
Availability 
Weapon  Effects 
Target  Characteristics 


Tasking 


Request 


.  Forward  Element  in 
.  Need  of  Fire  Support 


Figure  2:  Concept  of  Operations 


1 .6  INITIAL  PROBLEM  FORMULATION  AND  SCOPE 


The  transformation  of  the  DoD  from  traditional  roles  and  equipment  into 
scalable,  expeditionary  units  demands  effective  JFS.  The  overall  reduction  in  the 
organic  fire  support  capability  of  proposed  future  ground  and  littoral  forces  is 
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driving  a  requirement  for  responsive  and  reliable  fire  support  from  any  available 
weapon,  regardless  of  service  component.  There  is  an  increased  risk  to  any 
military  mission  if  it  cannot  get  the  fire  support  it  needs  at  the  time  and  place 
needed.  This  risk  can  be  reduced  through  sound  operational  planning,  but  not  all 
fire  support  needs  can  be  anticipated.  Military  elements  that  are  presented  with 
unplanned  opportunities  that  could  benefit  from  effective  JFS  may  not  be  able  to 
take  advantage  of  them  due  to  a  lack  of  timely  support. 

It  is  essential,  therefore,  that  integrated  functional,  physical,  and 
operational  architectures  are  developed  that  efficiently  link  joint  fires  requests 
with  weapon  system  tasking.  Within  these  architectures,  the  mechanisms  and 
entities  processing  and  tasking  the  requests  to  the  weapon  systems  need  to  be 
identified  and  assessed.  The  most  basic  needs  of  such  a  construct  would 
include  speed  of  response  and  effectiveness  of  target-weapon  pairings. 
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2.0  PROBLEM  DEFINITION 


2.1  NEEDS  ANALYSIS 

In  order  to  understand  the  challenges  of  designing  a  joint  fires  system,  the 
purpose  and  functions  of  the  proposed  system  must  be  completely  understood. 
According  to  Blanchard  and  Fabrycky,  “The  identification  of  a  problem  and 
associated  definition  of  need  provides  a  valid  and  appropriate  starting  point  for 
design  at  the  conceptual  level.”®  The  Needs  Analysis  that  was  performed  for  the 
Joint  Fire  Support  in  2020  began  with  the  identification  of  a  “desire”  for  Joint  Fire 
Support  that  was  based  on  a  real  deficiency  in  execution.  The  remainder  of  the 
Needs  Analysis  translates  the  “broadly  defined  ‘want’  into  a  more  specific 
system-level  requirement.”^®  By  addressing  questions  such  as:  What  are  the 
functions  that  the  system  needs  to  perform?  And  When  and  how  often  does  the 
system  need  to  perform  these  functions?,  the  Needs  Analysis  defines  the 
WHATs  of  the  problem  and  avoids  the  HOWs.^^ 

2.1.1  Context  and  Components 

In  order  to  provide  a  useful  and  accurate  solution,  the  designer  must  first 
completely  understand  the  problem  and  the  context  in  which  it  exists.  To  do  this, 
we  must  define  all  of  the  elements  and  components  that  affect  the  system.  Fires 
are  “the  effects  of  lethal  or  nonlethal  weapons”  and  fire  support  is  defined  as 
“fires  that  directly  support  land,  maritime,  amphibious,  and  special  operations 
forces  to  engage  enemy  forces,  combat  formations,  and  facilities  in  pursuit  of 
tactical  and  operational  objectives. Joint  Fires  are  simply  “fires  produced 
during  the  employment  of  forces  from  two  or  more  components  in  coordinated 
action  toward  a  common  objective.”^®  Those  fires  may  be  from  similar  weapon 

®  B.S.  Blanchard  and  W.J.  Fabrycky,  Systems  Engineering  and  Analysis,  4th  ed.,  Pearson 
Prentice  Hall,  2006,  p.  54. 

Ibid,  p.  56. 

"  Ibid. 

Department  of  Defense,  Doctrine  for  Joint  Fire  Support,  Joint  Pub3-09,  May  1 998,  p.  1-1 . 

Ibid. 
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systems  like  Air  Force,  and  Navy  aircraft,  or  from  completely  dissimilar  weapon 
systems. 

The  challenges  to  joint  fires  execution  may  include  the  weapon  tactics,  the 

weapon  release  authority,  or  the  deconfliction  of  weapon  effects.  Joint  Fires  are 

not  specific  to  weapon  systems  or  missions,  but  are  defined  by  their  effects  and 

the  component  source.  According  to  the  Joint  Pub, 

Joint  Fire  Support  may  include,  but  is  not  limited  to,  the  lethal 
effects  of  close  air  support  (CAS)  by  fixed-  and  rotary-wing  aircraft, 

NSFS,  artillery,  mortars,  rockets,  and  missiles,  as  well  as  nonlethal 
effects  such  as 

A  common  tool  used  to  describe  the  necessary  sequence  of  events 
leading  to  destruction  of  a  target  is  called  the  Find,  Fix,  Track,  Target,  Engage, 
Assess  (F2T2EA)  model. This  sequence  of  events  is  often  referred  to  as  the 
“kill  chain”  and  covers  the  entire  lifespan  of  a  target,  from  discovery  through 
confirmed  destruction.  Although  several  DoD  components,  government 
agencies,  and  contractors  have  defined  alternative  models  to  describe  this 
process,  the  basic  process  is  identical  in  all  of  these  models.  In  the  context  of 
the  F2T2EA  model,  the  proposed  system  examines  the  JFS  process  from  the 
end  of  the  track  phase  through  targeting  to  the  beginning  of  engagement.  The 
F2T2EA  model  and  the  portions  of  the  kill  chain  studied  in  this  project  are  shown 
in  Figure  3. 


'''  Department  of  Defense,  Doctrine  for  Joint  Fire  Support,  Joint  Pub  3-09,  May  1998,  p.  I-1 . 
US  JFCOM,  Joint  Networked  Fires  Capabilities  JNFC  Roadmap,  30  September  2004,  p.10. 
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Figure  3:  F2T2EA  Concept  and  Design  Area 


The  design  challenge  of  this  project  was  to  create  a  framework  for  an 
improved  system,  but  the  multifaceted  nature  of  JFS  required  boundaries  on  the 
areas  addressed  by  this  study.  The  scope  of  this  project  included  the  actual 
request  for  fire  support,  but  not  the  means  by  which  the  target  was  found, 
identified,  and  tracked  nor  the  methods  and  equipment  by  which  the  necessary 
request  data  was  compiled  into  the  request.  This  is  the  final  step  of  the  Track 
phase.  Likewise,  future  engagements  will  undoubtedly  utilize  tactics  and 
weapons  that  are  impossible  to  predict  accurately.  For  these  reasons,  this 
design  only  included  the  tasking  of  the  weapon  to  service  a  target  and  not  the 
future  hardware  that  will  be  used  to  send  and  acknowledge  the  tasking.  It  also 
does  not  specify  the  methods  or  tactics  by  which  the  target  should  be  engaged  or 
the  required  outcome  from  that  engagement.  This  is  the  first  step  in  the  Engage 
phase.  Additionally,  this  system  design  does  not  include  a  mechanism  for  Battle 
Damage  Assessment  (BDA)  of  tasked  targets  or  the  ability  of  BDA  results  to 
force  another  engagement  of  the  target. 

Another  large  facet  of  JFS  that  was  not  specifically  tackled  in  this  report 
was  the  deconfliction  of  joint  fires.  Deconfliction  of  fires  is  a  task  that  must  be 
accomplished  throughout  fire  support  planning,  tasking,  and  execution.  This 
includes  not  only  deconfliction  between  weapon  systems  (i.e.,  artillery  and  CAS), 
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but  also  deconfliction  between  weapons  effects  and  the  environment  (i.e., 
fratricide  and  collateral  damage).  Deconfliction  is  an  area  that  requires 
considerable  future  study  and  although  this  project  does  not  specifically  address 
it,  many  of  the  insights  gained  from  this  study  can  be  leveraged  towards 
improved  deconfliction. 

Additionally,  the  hardware  system  and  methodology  used  to  prioritize 
requests  was  not  studied  in  this  report.  The  mechanisms  by  which  the  fire 
support  requests  will  be  prioritized  are  assumed  to  exist.  There  are  numerous 
methods  for  prioritization  of  requests  and  a  future  system  will  have  to  be  built  to 
perform  a  prioritization.  The  choice  of  the  best  way  to  prioritize  requests  is 
another  area  that  will  require  additional  study  and  analysis  outside  of  this  report. 

2. 1. 1. 1  Evolution  of  Fire  Support 

As  the  lethality  and  mobility  of  weapons  improves,  the  process  by 
which  those  weapons  are  employed  should  also  improve  to  take  full  advantage  of 
new  capabilities.  JFS,  as  we  think  of  it  today,  epitomizes  the  complexity  of 
modern  warfare  and  its  evolution  from  battles  won  by  virtue  of  mass  towards 
battles  won  through  synergistic  effects.  Fire  support  for  forward  ground  units  is 
not  a  new  concept  and  it  has  been,  for  the  most  part,  the  sole  dominion  of  the 
artillery  since  well  before  Napoleon.  Although  naval  gunfire  was  sometimes  used 
in  preparation  for  a  ground  assault  or  amphibious  landing,  it  was  not  used  in 
concert  with  ground  force  maneuvers  until  much  later.  In  fact,  the  concept  of 
non-artillery  fire  support  of  ground  forces  was  not  practiced  until  the  evolution  of 
CAS  around  the  beginning  of  the  20*'^  century.  Until  then,  the  weapons  available 
to  each  military  branch  didn’t  possess  enough  range  and  accuracy  to  effectively 
support  the  other  and  therefore  didn’t  merit  the  coordination  and  training  involved 
to  do  so.  Each  service  component  essentially  fought  by  itself — Army  supported 
Army  and  Navy  supported  Navy.  As  a  result  of  this  exclusivity,  the  organizations 
and  procedures  for  fire  support  were  tailored  to  the  capabilities  of  the  weapons 
systems  being  employed.  In  a  simultaneous  growth  process,  the  procedures  and 

methods  of  fire  support  were  developed  in  parallel  with  the  capabilities  of  the 
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weapon  and  communication  abilities.  This  has  led  to  organizations  that  were 
built  to  fit  the  weapon  and  integrate  it  into  the  service  branch.  Even  today,  that 
legacy  continues  to  an  extent  in  the  organizations  and  control  systems  being 
developed  to  “include”  new  weapons  into  the  battlespace. 

The  complexity  of  executing  effective  fire  support  can  present 

daunting  DOTMLPF  challenges  to  military  leaders  that  can  result  in  lost  or 

passed  up  opportunities  in  training  and  battle.  Despite  the  expanded  capabilities 

of  today’s  joint  fires,  military  leaders  are  sometimes  reluctant  to  completely  rely 

on  those  capabilities  or  engage  the  enemy  in  a  way  that  challenges  historical 

truisms.  For  instance,  despite  the  plethora  of  long-range,  joint  fires  available  to 

today’s  ground  commander,  they  are  typically  reluctant  to  advance  at  a  faster 

rate  than  their  artillery  support  can  sustain.  With  regard  to  CAS, 

Recent  conflicts  in  Kosovo,  Iraq  and  Afghanistan  have  shown  Joint 
Close  Air  Support  successes  and  failures.  Since  the  evolution  of 
Close  Air  Support  in  Vietnam,  the  Army  and  Air  Force  had  grown 
apart.  Successes  were  forgotten  and  correct  doctrine  was  not 
documented.  Differences  in  equipment,  doctrine,  attitude  and 
outlook  inhibited  integration.^® 

Despite  the  evolution  of  equipment  on  and  above  the  battlefield,  for  the  most  part 
the  fire  support  integration  measures  and  techniques  developed  during  the 
Vietnam  Conflict  are  still  being  used  today. 

The  evolution  of  technology  and  its  proliferation  onto  the  battlefield 
has  enabled  changes  in  the  Joint  Fires  integration  processes,  but  the  measures 
used  to  integrate  those  fires  have  not  changed  significantly.  Due  to  historical  or 
other  reasons,  the  service  components  have  “paired  up”  and  declared 
themselves  joint;  the  Army  with  the  Air  Force  and  the  Navy  with  the  Marines. 
Unfortunately,  these  pairings  have  not  adopted  similar  organizational  structures 
and  methodologies  that  could  also  be  applied  to  components  outside  of  the  pair. 
Fires  that  are  truly  “Joint”  will  include  and  synchronize  weapons  from  across  the 


A.E.  Lindahl,  “Integrating  Naval  Surface  Fire  Support  into  an  Improved  Joint  Close  Air 
Support  Architecture,”  Master’s  Thesis,  Naval  Postgraduate  School,  Monterey,  California, 
June  2006,  p.  15. 
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spectrum  of  the  armed  forces,  including  traditional  air  power  from  all  service 
components,  artillery,  naval  fires,  guided  missiles,  and  unmanned  vehicles. 
Effective  Joint  Fire  Support  will  be  the  fusion  of  these  diverse  weapons 
capabilities  and  limitations  into  a  usable  benefit  for  the  supported  commander. 
Despite  this  straightforward  description.  Joint  Fires  is  difficult  to  execute 
effectively,  primarily  due  to  the  number  of  entities  and  conflicting  requirements 
involved. 


JFS  in  the  future  should  continue  to  evolve  into  a  system  that  is 
focused  on  the  effects  of  the  weapon  instead  of  the  employment  of  the  weapon. 
This  evolved  system  will  be  flexible  with  respect  to  the  weapons  available  and 
employed  because  effects  can  be  applied  regardless  of  the  weapon.  This 
approach  will  enable  the  service  components  to  standardize  and  restructure  their 
JFS  organizations  into  units  that  are  built  around  generic  weapon  capabilities  or 
functions,  not  a  specific  type  of  weapon. 

2.1.2  Existing  Command  and  Control  (C2)  Relationships 

Although  sometimes  used  synonymously.  Command  and  Control  are 

separate  functions  that  are  applied  simultaneously  by  the  military  leader. 

Command  concepts  are  primarily  applied  to  organization  and  authority 

relationships  whereas  the  concepts  of  Control  deal  primarily  in  the  flow  of 

information  and  intent.  The  Joint  Chiefs  of  Staff  define  Command  and  Control  as 

The  exercise  of  authority  and  direction  by  a  properly  designated 
commander  over  assigned  and  attached  forces  in  the 
accomplishment  of  the  mission.  Command  and  control  functions 
are  performed  through  an  arrangement  of  personnel,  equipment, 
communications,  facilities,  and  procedures  employed  by  a 
commander  in  planning,  directing,  coordinating,  and  controlling 
forces  and  operations  in  the  accomplishment  of  the  mission. 

C2  systems  bring  all  applicable  information  together  for  collation  and  decision 
making.  C2  systems,  personnel,  equipment,  and  a  variety  of  related  procedures 
support  the  execution  of  JFS  missions.  Unity  of  effort  is  one  of  the  keys  to  the 

Department  of  Defense,  Department  of  Defense  Dictionary  of  Military  and  Associated 
Terms,  Joint  Pub  1-02,  12  April  2001,  p.  101. 
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effective  coordination  of  JFS.  Vertical  and  horizontal  coordination  is  also 
essential  for  effective  JFS.  For  this  reason,  service  and  functional  components 
currently  provide  a  hierarchy  of  fire  support  coordinators,  fire  support 
coordination  agencies,  and  liaison  officers.  These  fire  support  entities  have  one 
goal  in  common — to  efficiently  direct  the  use  of  fire  support  to  accomplish  the 
mission.  However,  the  number  and  sheer  variety  of  C2  systems  challenges 
these  entities  to  comprehend  different  information  from  different  systems  in  order 
to  make  fire  support  decisions.  For  example,  the  screen  displays  of  a  few  of  the 
more  prevalent  C2  systems  are  shown  in  Figure  4.  Although  the  information 
displayed  by  these  systems  is  similar,  the  presentation  of  that  information  is  very 
different  between  these  systems. 


CPOF 


C2PC 


TBMCS 


Figure  4:  Sample  of  C2  System  Duplicity 


Currently,  each  of  DoD’s  service  components  use  different  C2  systems  to 

manage  its  operations.  For  example,  the  Marine  Corps  maintains  the  Command 

and  Control,  Personal  Computer  (C2PC)  as  its  primary  C2  system.  The  Army 

maintains  the  Command  Post  of  the  Future  (CPOF),  part  of  the  Maneuver 

Control  System  (MCS),  at  its  division  level  but  has  separately  developed  systems 

at  other  levels,  such  as  Force  XXI  Battle  Command,  Brigade  and  Below  (FBCB2) 
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and  Blue  Force  Tracker  (BFT).  The  Air  Force  maintains  the  Global  Command 
and  Control  System,  Air  Force  (GCCS-AF)  and  the  Theater  Battle  Management 
Core  System  (TBMCS)  as  its  primary  C2  systems.  The  Navy  maintains  a 
completely  different  version  of  GCCS  called  Global  Command  and  Control 
System-Maritime  (GCCS-M)  as  its  primary  C2  system.  However,  the  Navy  also 
has  a  capability  to  receive  inputs  from  TBMCS  and  is  projecting  a  level  of 
interoperability  with  C2PC. 

The  C2  required  for  JFS  requires  intensive  coordination  between  affected 
agencies.  Two  interrelated  functions  account  for  the  complexity  of  this 
coordination:  planning  and  coordination,  and  execution  planning.  The  first  of 
these  functions  is  the  overall  C2  planning  process  for  employing  fire  support 
assets  within  a  service  or  functional  component  during  joint  operations.  This 
process  includes  fire  support  planning  and  coordination,  tactical  fire  direction 
procedures,  air  operations  procedures,  and  other  general  supervisory  tasks. 

The  second  interrelated  function  involves  the  tactical  planning  required  to 
execute  JFS  missions.  This  execution  planning  provides  the  requisite  technical 
parameters — including  weather  data,  terrain,  target  location  data,  defenses,  and 
weapon  system  data — needed  to  deliver  accurate  JFS.  The  many  different 
platforms  and  training  and  execution  requirements  set  by  each  of  the  services 
complicates  the  process  further.  This  often  leads  to  a  wide  variability  in  the 
execution  of  Joint  Fires  between  commanders.  For  this  reason,  technical 
execution  planning  is  normally  accomplished  within  a  single  service  or  functional 
component,  although  some  input  of  data  may  come  from  outside  the  service  or 
functional  component.^® 

2.1.3  Existing  Organizational  Components 

As  a  result  of  many  years  of  organizational  and  leadership  refinement, 
today’s  military  operations  are  executed  under  the  construct  of  the  Joint  Force 
Commander  (JFC).  In  this  chain  of  command,  the  JFC  is  the  single  responsible 


Department  of  Defense,  Doctrine  for  Joint  Fire  Support,  Joint  Pub  3-09,  May  1998,  p.  II-5. 

18 


agent  for  the  Joint  Force  Area  of  Operations  (JFAO).  Each  military  branch  which 
operates  within  the  JFAO  aligns  its  service-specific  chain  of  command  under  the 
JFC  and  provides  its  most  senior  leadership  to  his  support  staff.  Establishing 
supported  and  supporting  command  relationships  among  or  between 
components  helps  the  Joint  Force  Commander  integrate  operations  inside  the 
JFAO.  Although  sometimes  challenged  by  service  parochialisms,  command 
relationships  are  defined  and  clarified  in  the  Joint  Publications  issued  by  the  Joint 
Chiefs  of  Staff.^®  However,  because  every  theater  of  operations  is  unique,  the 
overall  military  commander  must  specifically  define  the  command  relationships 
within  their  area  of  operations.  A  generic  joint  task  force  upper-echelon 
command  hierarchy  is  illustrated  in  Figure  5. 


Department  of  Defense,  Doctrine  for  Joint  Fire  Support,  Joint  Pub  3-09,  May  1998,  pp.  1- 
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POSSIBLE  COMPONENTS  IN  A  JOINT  FORCE 


JOlhTT  FORCE 
COMMANDER 


MOTES: 

{1 )  A  jol  nt  force  contai  ns  Serv  ice  com  ponents  {because  of  log  istic 

and  train hg  responsibilities),  even  when  operations  are  conducted  -  \ 

th  roug  h  fij  nctional  com  ponents.  command  rh. AnowsHiPisj 

OeTERMl^eo  BV  JFC 

(2)  AJI  Serv  ice  and  functionaJ  components  are  depicted;  any  mix 
of  the  above  components  can  constitute  a  joint  force. 

(3)  There  may  also  be  a  Coast  Guard  component  in  a  Joint  force. 


Figure  5:  Possible  Joint  Force  Organization  (From^°) 


Successful  military  campaigns  depend  on  how  effectively  all  the  elements 
of  joint  fires  are  coordinated  within  a  Joint  Force  Area  of  Operations.  Within  the 
JFAO,  a  high  density  of  friendly  weapons  systems  and  air  power  vehicles,  with 
overlapping  operating  envelopes  and  flight  profiles,  must  contribute  maximum 
combat  effectiveness  without  interfering  with  each  other.  All  weapon  platforms 
must  be  coordinated  effectively  without  hindering  the  blue  force  combat 
maneuvers.  The  JFC,  through  his  component  commanders,  with  the  assistance 
of  their  staffs,  controls  the  JFAO  at  the  Joint  Operations  Center  (JOC).  These 
staffs  are  responsible  for  the  organization,  personnel,  procedures,  and 


Department  of  Defense,  Unified  Action  Armed  Forces  (UNAAF),  Joint  Pub  0-2, 
10  July  2001,  p.  V-3. 
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equipment  necessary  to  plan,  direct,  and  control  joint  fires  operations  by 
coordinating  fires  amongst  the  services  (and  allied  forces,  when  required). 

To  execute  a  plan  for  Joint  Fires,  it  is  imperative  that  the  services  be 
flexible,  versatile,  and  have  a  common  understanding  of  joint  doctrinal  matters 
and  terminology.  Even  when  speaking  the  same  language,  communicating  intent 
jointly  across  the  services  has  been  a  stumbling  block  due  to  cultural  and  service 
differences  in  terminology  and  organization  and  translating  the  understanding 
into  actionably  items  that  have  the  intended  results.  For  example,  each  service 
has  an  organization  and/or  an  individual,  who  plans  for  the  use  of  air  power, 
controls  the  function  of  air  defense,  coordinates  air-to-ground  support  operations, 
and  coordinates  ground  fires.  Each  of  these  entities  performs  similar,  if  not 
identical,  functions  within  their  service  but  depending  on  the  component,  each 
organization  or  individual  has  a  different  title  and  command  relationship. 

The  combatant  commanders,  through  subordinate  commands,  assign 
responsibilities,  establish  or  delegate  appropriate  command  and  support 
relationships,  and  establish  coordinating  instructions  to  effect  Joint  Fires 
coordination.  Fire  support  coordination  includes  efforts  to  deconflict  attacks, 
avoid  fratricide,  reduce  duplication  of  effort,  and  assist  in  shaping  the 
battlespace.^^  As  an  example  of  the  complexity  of  these  relationships,  the 
coordination  of  air-to-ground  fires  is  connected  through  the  organizations  or 
systems  shown  in  Figure  6.  Keep  in  mind  that  Figure  6  only  shows  the  lines  of 
authority  and  communication  for  air-to-ground  fire  support  (i.e.,  CAS)  and  not  the 
entire  fire  support  organization.  A  complete  list  of  the  acronyms  used  in  Figure  6 
is  provided  in  Table  1  following  the  figure. 
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Figure  6:  Theater  Air  Ground  System  Coordination  Links  (From^^) 
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ABCCC 

airborne  battlefield  command  and  control 

JAOC 

joint  air  operations  center 

center 

JFACC 

joint  force  air  component  commander 

ACE 

aviation  combat  element 

JMCC 

Joint  Movement  Control  Center 

ADA 

air  defense  artillery 

JOC 

Joint  Operations  Center 

AFARN 

Air  Force  Air  Request  Net 

JSTARS 

joint  surveillance,  target  attack  radar  system 

AFFOR 

Air  Force  forces 

MAGTF 

Marine  air-ground  task  force 

AFSOC 

Air  Force  special  operations  component 

MARLO 

Marine  liaison  officer 

AME 

air  mobility  element 

MEF 

Marine  expeditionary  force 

AMLS 

airspace  management  liaison  section 

MLE 

Marine  liaison  element 

AOC 

air  operations  center  (USAF) 

NALE 

naval  and  amphibious  liaison  element 

ASOC 

air  support  operations  center 

RECCE 

reconnaissance 

AWACS 

airborne  warning  and  control  system 

SF 

special  forces 

BCD 

battlefield  coordination  detachment 

SOLE 

special  operations  liaison  element 

BDE 

brigade 

TAC(A) 

tactical  air  coordinator  (airborne) 

BN 

battalion 

TACC 

tactical  air  command  center  (USMC); 

CCT 

combat  control  team 

tactical  air  control  center  (DSN); 

CRC 

control  and  reporting  center 

tanker  airlift  control  center  (USAF) 

CRE 

control  and  reporting  element 

TACP 

tactical  air  control  party 

DIRMOBFOR 

Director  of  Mobility  Forces 

TARN 

Tactical  Air  Request  Net 

DIV 

division 

TALCE 

tanker  airlift  control  element 

FAC(A) 

forward  air  controller  (airborne) 

TADC 

Tactical  Air  Direction  Center 

FSCC 

GLO 

Fire  Support  Coordination  Center 

Ground  Liaison  Officer 

woe 

Wing  Operations  Center 

Table  1:  Theater  Air-to-Ground  System  Coordination  Agencies 

In  order  to  better  understand  these  existing  organizational  components, 
the  following  sections  (arranged  by  service  component)  describe  the  functions  of 
these  key  service  organizations  that  advise  commanders  on  the  use  of 
Joint  Fires. 


2. 1.3. 1  Army  Fire  Support  Organizations 

The  Army  provides  the  Army  Forces  Commander  (ARFOR)  to  the 
JFC  staff.  ARFOR  is  responsible  for  all  Army  forces  within  the  JFAO  and  is 
subordinate  to  the  JFC. 

ARFOR  establishes  a  staff  to  assist  him  in  the  execution  of  his 
duties.  With  respect  to  the  coordination  of  battlefield  functions,  a  Battlefield 
Coordination  Detachment  (BCD)  is  created.  The  BCD  provides  direction  to 
subordinate  army  units  and  acts  as  the  senior  liaison  between  ARFOR  and  the 
other  services.  The  BCD  is  usually  collocated  with  the  Air  Operations  Center 
(AOC)  or  Joint  Air  Operations  Center  (JAOC).  The  BCD  is  also  the  army’s 
primary  liaison  with  other  specialized  functions  like  the  Air  Force  Air  Mobility 
Element  (AME),  the  Marine  Liaison  Officer  (MARLO),  the  Naval  and  Amphibious 
Liaison  Element  (MALE),  and  the  Special  Operations  Liaison  Element  (SOLE). 
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The  BCD  interface  includes  exchanging  current  intelligence  and  operational  data. 
The  BCD  is  not  a  Fire  Support  Element  (FSE),  but  acts  as  the  ARFOR  senior 
liaison  element  and  also  can  perform  many  fire  support  functions.  Figure  7 


illustrates  a  simplified  Army  organizational  structure  for  fire  support. 


Figure  7:  Simplified  Army  Organizational  Structure  for  Fire  Support 


At  the  company  level,  the  basic  fire  support  organization  is  called 
the  Fire  Support  Team  (FIST).  The  FIST  is  led  by  the  company  Fire  Support 
Officer  (FSO).  The  FIST  coordinates  field  artillery  and  mortar  fire  support  for  the 
company.  When  it  is  available,  the  FIST  initiates  the  request  and  helps 
coordinate  the  delivery  of  CAS  and  naval  fires.  In  addition  to  the  FSO,  the  FIST 
may  directly  interface  with  other  specially  trained  personnel  such  as  the  Forward 
Air  Controller  (FAC),  Forward  Observer  (FO),  Air  Liaison  Officer  (ALO),  Navy 
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Ground  Liaison  Officer  (NGLO),  Combat  Lasing  Teams,  or  others. 

At  the  battalion  and  brigade  levels,  the  basic  fire  support 
organization  is  called  the  Fire  Support  Cell  (FS  Cell).  The  FS  Cell  is  led  by  the 
Fire  Support  Coordinator  (FSCOORD).  Typically,  the  senior  field  artillery 
commander  is  designated  the  FSCOORD  and  therefore  serves  as  the  maneuver 
commander’s  principal  assistant  for  the  integration  and  application  of  fire  support. 
The  FS  Cells  coordinate  field  artillery  and  mortar  fire  support  for  subordinate 
FISTs  and  between  adjacent  fielded  units.  Additionally,  the  FS  Cell  helps 
coordinate  CAS  and  naval  fires.  The  FS  Cells  are  located  in  the  maneuver 
Tactical  Operations  Center  (TOC). 

The  division  also  maintains  a  FS  Cell.  In  addition  to  coordinating 
artillery  and  mortar  support,  these  units  also  support  specialized  functions  like 
the  Deep  Operations  Coordination  Cell  (DOCC),  coordination  with  Army  aviation 
units.  Electronic  Warfare  (EW)  support  elements.  Air  Force  Tactical  Air  Control 
Party  (TACP)  planning,  and  others. 

The  Army  uses  a  wide  variety  of  equipment  to  complete  its  fire 
support  missions.  The  equipment  fielded  today  will  no  doubt  be  improved  in  the 
future.  The  following  discussion  of  particular  systems,  in  addition  to  providing  a 
general  background  in  the  topic,  is  designed  to  outline  the  desired  functions  of 
such  systems  so  they  may  be  reproduced  in  the  overall  system  design. 

In  order  to  conduct  coordinated  artillery  and  mortar  fire  support 
efficiently,  each  FIST  team  is  equipped  with  a  Target  Location,  Designation,  and 
Hand-off  System  (TLDHS)  or  similar  equipment  that  is  compatible  with  the 
Advanced  Field  Artillery  Tactical  Data  System  (AFATDS).  The  TLDHS  allows 
operators  to  accurately  determine  their  own  location,  the  location  of  their  targets, 
and  digitally  transmit  (hand-off)  this  data  to  supporting  arms  elements  through 
AFATDS.  Once  received  by  AFATDS,  AFATDS  terminals  at  the  FS  Cell  provide 
fully  automated  support  for  planning,  coordinating,  controlling,  and  executing  fires 
and  effects.  The  TLDHS  and  AFATDS  combination  may  be  networked  from  the 
FIST  to  the  BCD,  providing  a  common  operating  picture  to  connected  units. 
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Portions  of  this  network  (usually  at  the  battalion  and  below)  are 
maintained  via  FM  radio  links  (SINCGARS/JTRS  radios)  which  have  low  data 
rates  (1-10  kb/s).  Above  the  battalion,  more  robust  connectivity  via  the  TCP/IP 
backbone  significantly  reduces  network  latency.  However,  since  virtually  all  of 
the  requests  for  fires  originate  from  a  company  FIST  or  a  battalion  FS  Cell,  data 
rates  remain  a  concern. 

The  primary  method  to  request  Close  Air  Support  (CAS)  involves  a 
VHF/UHF  radio  and  the  Air  Force  Air  Request  Network  (AFARN).  While 
targeting  information  may  have  been  collected  via  TLDHS/AFATDS,  the  CAS 
request  will  be  sent  by  voice  and  recorded  manually  onto  a  DD  Form  1972,  Joint 
Tactical  Air  Strike  Request  (The  AFARN  will  be  described  in  the  Air  Force 
section  below). 

2. 1.3.2  Navy  Fire  Support  Organizations 

The  Navy  provides  the  Naval  Forces  Commander  (NAVFOR)  to  the 
JFC  staff.  NAVFOR  is  responsible  for  all  Navy  forces  within  the  JFAO  and  is 
subordinate  to  the  JFC.  Due  to  the  close  ties  with  the  Marine  Corps,  NAVFOR 
has  two  primary  divisions  under  him:  the  Commander,  Task  Force  (CTF),  which 
deals  with  the  fleet,  and  the  Marine  Air-Ground  Task  Force  (MAGTF),  which 
deals  with  all  Navy  support  to  the  Marine  Corps.  A  Marine  Expeditionary  Force 
(MEF)  can  be  compared  directly  to  a  MAGTF  and  their  differences  have  more  to 
do  with  overall  campaign  timing  than  organizational  structure. 

The  CTF  has  three  divisions  that  cover  Navy  operations  from  the 
shore  to  the  open  ocean:  the  Commander,  Landing  Forces  (CLF),  the 
Commander,  Amphibious  Task  Force  (CATF),  and  the  Commander,  Carrier 
Strike  Group  (CSG).  A  simplified  Navy  organizational  structure  for  fire  support  is 
shown  in  Figure  8. 
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Figure  8:  Simplified  Navy  Organizational  Structure  for  Fire  Support 


In  order  to  effectively  and  efficiently  address  the  dynamics  of  Navy 
and  Marine  landing  operations,  two,  cross-service,  single  point-of-contact 
organizations  have  been  created.  The  first  of  these  is  the  Supporting  Arms 
Coordination  Center  (SACC),  which  coordinates  all  artillery  and  most  naval 
surface  fires.  The  second  is  the  Tactical  Air  Coordination  Center  (TACC),  which 
coordinates  air  support  from  Marine  or  Navy  aviation  units.  The  SACC  and 
TACC  serve  the  requirements  of  both  the  Navy  and  Marine  Corps. 
Organizationally,  the  SACC  and  TACC  usually  report  directly  to  CATF,  but  there 
are  many  other  formal  and  informal  command  and  control  links  which  evolve 
during  an  operation. 

During  the  initial  phase  of  an  amphibious  operation,  while  control 
and  coordination  responsibility  of  supporting  arms  is  still  afloat,  the  Marine  Air- 
Ground  Task  Force  (MAGTF)  typically  provides  the  landing  force  representation 
in  the  Navy’s  Supporting  Arms  Coordination  Center  (SACC).  Functioning  as  a 
Fire  Support  Element  for  the  naval  forces,  the  SACC  is  supervised  by  the 
supporting  arms  coordinator. 

In  an  amphibious  operation,  the  Commander,  Amphibious  Task 
Force  (CATF)  exercises  the  overall  responsibility  for  coordination  of  Naval 
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Surface  Fire  Support  (NSFS),  air  support,  and  landing  force  artillery  fire  support. 
When  the  Commander,  Landing  Force  (CLF),  normally  the  MAGTF  commander, 
is  established  ashore,  the  CATF  may  pass  this  responsibility  to  the  CLF.  Once 
the  passage  of  control  ashore  is  executed,  the  CLF  will  coordinate  fires  within  the 
AO.  When  control  is  afloat,  the  senior  naval  fire  support  coordination  agency  is 
the  SACC.  The  SACC  is  then  the  primary  agency  that  coordinates  and  controls 
all  supporting  fires  for  the  CATF  in  order  to  establish  the  landing  force  ashore. 

Despite  the  operation  of  the  SACC,  control  of  the  naval  surface  fire 
assets  (i.e.,  the  ships  which  carry  the  naval  guns,  rockets,  and  missiles)  is 
retained  by  the  CVBG.  The  carrier  battle  group  maintains  strike  planning  and 
operations  staffs  to  deconflict  SACC  direction  and  to  perform  specialized  support 
for  certain  assets.  These  relationships  are  further  defined  in  Joint  Pub  3-02, 
“Joint  Doctrine  for  Amphibious  Operations,”  and  Joint  Pub  3-02.1,  “Joint  Tactics, 
Techniques,  and  Procedures  for  Landing  Force  Operations.” 

The  Tactical  Air  Control  Center  (TACC)  controls  all  air  operations 
within  the  Amphibious  Objective  Area  (AOA).  Like  the  Air  Force  Air  Operations 
Center  (AOC),  the  TACC  is  responsible  for  planning  and  conducting  Close  Air 
Support  (CAS).  Its  air  support  control  section  coordinates  with  the  SACC  to 
integrate  CAS  and  other  supporting  arms.  The  organizational  relationships  of 
these  Navy  and  Marine  organizations  are  illustrated  in  Figure  9. 

Within  the  TACC,  the  Direct  Air  Support  Center  (DASC)  is  the 
central  coordination  point  for  all  aircraft  support.  The  DASC  assigns  direct  air 
support  aircraft  to  terminal  control  agencies,  provides  aircraft  ingress  and  egress 
route  instructions,  disseminates  advisory  information,  and  other  key  tasks.  The 
DASC  conducts  its  operations  via  a  communications  network  referred  to  as  the 
Tactical  Air  Request  Net  (TARN). 

A  number  of  specially  trained  personnel  are  required  to  provide 
comprehensive  support.  The  Navy  has  established  the  positions  of  Air  and 
Naval  Gunfire  Liaison  Company  (ANGLICO),  Naval  Gunfire  Liaison  Officer 
(NGLO),  and  Forward  Air  Controller  (FAC). 

The  Navy  has  fielded  the  Naval  Fire  Control  System  (NFCS)  to 
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assist  in  the  coordination  of  most  naval  fires.  A  few  other,  stand-alone,  systems 
are  required  in  certain  cases.  In  the  future,  MFCS  should  have  a  degree  of 
interoperability  with  AFATDS.  These  systems  have  significant  capability  overlap 
which  has  been  noted  by  various  government  agencies  including  the  General 
Accounting  Office.^^ 

The  primary  method  to  request  CAS  involves  a  VHF/UHF  radio  to  send 
the  request  via  voice  over  the  TARN.  While  targeting  information  may  have  been 
collected  via  MFCS  or  AFATDS  (if  a  Marine  unit),  the  CAS  request  will  be 
translated  by  a  human  operator  into  a  Joint  Tactical  Air  Strike  Request. 

2.1. 3.3  Marine  Corps  Fire  Support  Organizations 

The  Marine  Corps  provides  the  Marine  Forces  Commander 
(MARFOR)  to  the  JFC  staff.  MARFOR  is  responsible  for  all  Marine  Corps  forces 
within  the  JFAO  and  is  subordinate  to  the  JFC. 

The  Marine  Air  Ground  Task  Force  (MAGTF)  or  Marine 
Expeditionary  Force  (MEF)  command  element  organizes  a  Force  Fires 
Coordination  Center  (FFCC),  which  is  responsible  for  fire  support  coordination 
within  the  Marine  Corps  and  the  primary  interface  with  the  SACC  for  coordinated 
actions.  At  each  level  below  the  MEF  command  element  (division,  regiment,  and 
battalion),  a  Fire  Support  Coordination  Center  (FSCC)  is  established  as  an 
advisory  and  coordination  agency  within  the  Ground  Combat  Element  (GCE). 
The  FFCC  and  each  FSCC  is  staffed  with  representatives  of  the  various  Marine 
Corps  and  Navy  supporting  arms. 

The  Marine  Tactical  Air  Control  Party  (TACP)  establishes  and 
maintains  facilities  for  liaison  and  communications  between  supported  units  and 
appropriate  control  agencies.  An  air  officer  leads  the  TACP,  normally  with  two 
teams  assigned  per  maneuver  battalion.  Their  mission  is  to  inform  and  advise 
the  supported  ground  unit  commander  on  the  employment  of  supporting  aircraft 
and  to  request  and  coordinate  air  support  missions.  In  addition,  the  TACP 
provides  final  attack  control  for  CAS  missions.  A  simplified  Marine  organizational 

Department  of  Defense,  Acquisition  of  the  Navai  Fires  Control  System,  Office  of  the 
Inspector  General  Report  No.  D-2002-036,  January  8,  2002,  pp.  1-49. 
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structure  for  fire  support,  including  the  ties  to  Navy,  is  shown  in  Figure  9. 


Figure  9:  Simplified  Marine  Organizational  Structure  for  Fire  Support 


The  supporting  Marine  Corps  artillery  battalions  provide  Shore  Fire 
Control  Parties  (SFCPs)  to  supported  units.  The  SFCP  consists  of  a  liaison  team 
and  a  spot  team.  The  liaison  team  is  headed  by  a  Navy  officer  and  is  located  in 
the  supported  battalion’s  Fire  Support  Coordination  Center  (FSCC).  The  FSCC 
is  a  single  location  that  centralizes  communications  facilities  and  personnel  for 
the  coordination  of  all  forms  of  fire  support.  The  FSCC  is  organized  and 
supervised  by  the  FSCOORD  and  is  collocated  with,  and  in  support  of,  the 
operations  officer.  The  SFCP  spot  team  is  led  by  a  Marine  Corps  officer  and  is 
normally  employed  with  the  maneuver  companies. 

There  are  very  few  differences  in  fire  support  between  the  Marine 
Corps  and  Army  below  the  brigade  (Army)  and  regiment  (Marine  Corps)  levels. 
Army  FSEs  and  Marine  FSCCs  are  virtually  identical  in  function  and  the  fire 
support  execution  methods  and  data  processing  equipment  used  are  the  same. 
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Even  though  they  are  organizationally  tied  to  the  Navy,  the  Marine  Corps  has 
designated  the  AFATDS,  not  MFCS,  as  their  preferred  system  for  fires  support. 

2. 1.3.4  Air  Force  Fire  Support  Organizations 

The  Air  Force  provides  the  Air  Forces  Commander  (AFFOR)  to  the 
JFC  staff.  AFFOR  is  responsible  for  all  Air  Forces  within  the  JFAO  and  is 
subordinate  to  the  JFC. 

The  Air  Force  component  commander  exercises  operational  control 
over  assigned  forces  through  the  Air  Operations  Center  (AOC)  or  Joint  Air 
Operations  Center  (JAOC).  The  AOC  implements  the  Theater  Air  Control 
System  (TACS).  Subordinate  TACS  elements  perform  the  tasks  of  planning, 
coordinating,  monitoring,  controlling,  reporting,  surveillance,  and  executing  air 
operations.  This  includes  creating  and  distributing  the  daily  plan  for  flying 
operations  called  the  Air  Tasking  Order  (ATO).  The  TACS  elements  include:  the 
Air  Support  Operations  Center  (ASOC),  the  Control  and  Reporting  Center  (CRC), 
the  Control  and  reporting  Element  (CRE),  Tanker  and  Air  Lift  Control  Element 
(TALCE),  and  TACPs.  TACS  functions  may  also  be  executed  from  airborne 
assets  such  as  the  Airborne  Warning  and  Control  System  (AWACS),  the  Joint 
Surveillance,  Target  Attack  Radar  System  (JSTARS),  and/or  an  Airborne 
Battlefield  Command  and  Control  Center  (ABCCC).  The  AOC  coordinates  CAS 
and  other  joint  air  operations  that  support  land,  amphibious,  and  maritime  forces. 
It  does  so  through  the  ASOC,  TACPs,  Forward  Air  Controllers  (FACs),  and  Air 
Liaison  Officers  (ALOs).  The  following  paragraphs  describe  key  Air  Force 
elements  that  relate  to  JFS. 

The  ASOC  is  the  key  Air  Force  TACS  agency  involved  in 
coordinating  CAS  for  ground  forces.  It  performs  coordination,  direction,  and 
control  of  the  air  effort  to  support  land  forces’  maneuver  objectives,  usually  at 
Army  corps  level  and  below.  The  ASOC  is  an  operational  component  of  the 
TACS,  subordinate  to  the  AOC.  The  ASOC  processes  requests  for  “immediate 
CAS”  which  have  been  submitted  by  ground  maneuver  forces.  These  requests 
are  sent  via  voice  over  the  AFARN  in  the  Joint  Tactical  Air  Strike  Request  format. 
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The  ASOC  also  tasks  aircraft  to  service  those  requests  in  accordance  with 
command  guidance.  The  established  TAGS  organization  between  the  Air  Force 
and  Army  elements  is  depicted  in  Figure  10. 


Figure  10:  Air  Force/Army  Coordination  Links  (From^'^) 


Additional  information  on  the  functions  of  specific  Air  Force  C2 
elements  can  be  found  in  Joint  Pub  3-09.3,  “Joint  Tactics,  Techniques,  and 
Procedures  for  Close  Air  Support  (CAS),”  and  Joint  Pub  3-56.1,  “Command  and 
Control  for  Joint  Air  Operations.” 

The  Air  Force  TACP  is  a  control  element  usually  stationed  with  and 
supporting  an  Army  combat  unit.  Air  Force  TACPs  are  not  normally  aligned  with 
Marine  Corps  combat  units.  Located  at  Army  corps,  division,  brigade,  and 
battalion  levels,  TACPs  are  tailored  to  the  unit  they  support.  The  TACP  provides 
the  interface  between  the  unit  it  supports  and  the  TAGS  system.  The  TACP 
advises  the  ground  commander  on  the  capabilities  and  limitations  of  tactical 
aircraft  and  weapons  and  assists  in  planning  for  tactical  air  support.  The  TACP 
also  provides  final  attack  control  for  CAS  missions.  However,  TACPs  above 
brigade  do  not  normally  perform  Forward  Air  Controller  (FAC)  functions.^^ 


Department  of  Defense,  Doctrine  for  Joint  Fire  Support,  Joint  Pub  3-09,  May  1998,  p.  II-13. 

Department  of  the  Army,  Army  Airspace  Command  and  Controi  in  a  Combat  Zone, 
Field  Manual  100-103,  October  1987,  p  1-8. 
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TACPs  are  under  the  operational  control  of  the  ASOC  or  senior  TACP  element 
deployed. 

The  FAC,  also  known  as  a  Joint  Terminal  Attack  Controller  (JTAC), 
is  a  member  of  the  TACP  who  executes  control  of  close  air  support  aircraft  and 
integrates  air  attacks  with  fire  and  maneuver  of  supported  ground  forces.  He 
may  operate  from  an  aircraft  airborne  or  from  a  ground  position.  The  FAC 
maintains  contact  with  the  CAS  aircraft,  other  TACS  elements,  and  the 
appropriate  fire  support  coordinator  or  ground  commander.  His  airspace 
functions  include  coordination  of  air  attacks  with  field  artillery.  Air  Defense 
Artillery  (ADA),  and  appropriate  aviation  elements  of  the  supported  force  in  the 
target  area.^® 

The  Control  and  Reporting  Center  (CRC)  is  directly  subordinate  to 
the  TACC  and  is  the  primary  TACS  radar  element  concerned  with  decentralized 
execution  of  air  defense  and  airspace  control  functions.  Within  its  area  of 
responsibility,  the  CRC  directs  the  region  or  sector  air  defense;  provides  threat 
warnings  to  friendly  aircraft;  provides  aircraft  guidance  or  monitoring  for  both 
offensive  and  defensive  missions;  relays  mission  changes  to  airborne  aircraft; 
coordinates  control  of  missions  with  subordinate  TACS  elements  and  other 
agencies;  and  provides  positive  identification  of  aircraft.  During  joint  operations, 
the  CRC  assigns  appropriate  hostile  airborne  targets  to  the  Army  air  defense 
system  through  the  air  defense  liaison  officer  (ADLO)  located  within  the  CRC.^^ 
The  AWACS  aircraft  provides  radar  control  and  surveillance  of  air  traffic.  It  can 
also  function  as  an  alternate  CRC  and  as  a  limited-capability  AOC.  As  a  result  of 
its  elevated  line-of-sight,  the  AWACS  can  establish  communication  linkages  with 
the  ground  AOC  allowing  it  to  also  communicate  warnings  and  surveillance 
reports  to  other  designated  liaison  agencies,  such  as  an  ASOC. 

Joint  Surveillance,  Target  Attack  Radar  System  (JSTARS)  is  a  joint 
surveillance,  targeting,  and  battle  management  C2  system  designed  to  provide 
near  real  time,  wide-area  surveillance  and  targeting  information  on  moving  and 


Department  of  the  Army,  Army  Airspace  Command  and  Control  in  a  Combat  Zone, 
Field  Manual  100-103,  October  1987,  p.  1-8. 
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stationary  ground  targets.  JSTARS  is  a  component  of  the  theater  wide  battle 
management  system  and/or  a  C2  platform  that  conducts  ground  surveillance  to 
develop  an  understanding  of  the  enemy  situation  and  supports  attack  operations. 
These  functions  support  the  primary  mission  of  JSTARS,  which  is  to  provide 
dedicated  support  of  ground  commander  requirements.  However,  the  JFC 
determines  the  most  effective  use  of  JSTARS  based  on  the  situation  and  the 
concept  of  operations. 

The  Air  Force  does  not  have  an  automated  system  to  process 
requests  for  fires  that  could  be  closely  compared  to  TLDHS,  AFATDS,  or  MFCS. 
Wide  variation  in  the  installed  equipment  across  the  fighter/bomber  fleet  would 
create  serious  interoperability  challenges  for  such  a  system.  JFIIT  has  compiled 
a  matrix  of  system  compatibility,  which  is  included  in  Appendix  A.  While  there 
have  been  numerous  exercises  and  demonstrations  that  have,  in  some  fashion, 
connected  the  “sensor-to-shooter,”  none  of  these  solve  the  problem  across 
the  organization. 

2.1. 3.5  Special  Operations  Forces  Fire  Support 

Organizations 

The  Joint  Forces  Special  Operations  Component  Commander 
(JFSOCC)  (or  Joint  Special  Operations  Task  Force  [JSOTF]  commander,  if 
established)  is  the  commander  within  a  unified  command,  subordinate  unified,  or 
JTF  on  the  proper  employment  of  SOF.  The  JFSOCC  is  responsible  for 
establishing  planning  and  coordinating  Special  Operations  (SO)  or  accomplishing 
such  operational  missions  as  they  may  be  assigned.  The  JFSOCC  will  normally 
be  the  commander  with  the  preponderance  of  SOF  and  the  requisite  C2 
capabilities.  When  the  geographic  combatant  commander  designates  a  JFC,  the 
theater  special  operations  command  may  be  designated  as  the  JFSOCC.  The 
JFSOCC  exercises  overall  responsibility  for  coordination  of  all  fire  support  in 
support  of  SO  and,  when  tasked,  fire  support  using  SOF  assets  in  support  of 
other  elements  of  the  joint  force.  A  simplified  SOF  organizational  structure  for 
fire  support  is  shown  in  Figure  1 1 . 


34 


JFC 

JOC 


Figure  1 1 :  Simplified  SOF  Operational  Structure  for  Fire  Support 


The  Joint  Special  Operations  Air  Component  Commander 
(JSOACC)  is  the  commander  within  the  joint  force  special  operations  component 
responsible  for  planning  and  executing  joint  special  air  operations  and  for 
coordinating  and  deconflicting  such  operations  with  conventional,  non-SO  air 
activities.  The  JSOACC  normally  will  be  the  commander  with  the  preponderance 
of  assets  and/or  greatest  ability  to  plan,  coordinate,  allocate,  task,  control,  and 
support  the  assigned  joint  special  operations  aviation  assets.  The  JSOACC  may 
be  subordinate  to  the  JFSOCC  (or  JSOTF  commander)  or  to  any  non-SO 
component  or  directly  subordinate  to  the  JFC.  The  Special  Operations 
Command  and  Control  Element  (SOCCE)  is  the  focal  point  for  the 
synchronization  of  SOF  activities  with  land  and  maritime  operations.  The 
SOCCE  is  normally  employed  when  SOF  conduct  operations  in  conjunction  with 
a  conventional  force.  It  is  collocated  with  the  command  element  of  the  supported 
commander  and  performs  C2  or  liaison  functions  directed  by  the  JFSOCC  (or 
JSOTF  commander).  The  focus  of  the  coordination  is  on  the  synchronization  of 
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effects  and  deconfliction  of  fires.  To  do  this,  the  Special  Operations  Liaison 
Element  (SOLE),  who  works  directly  for  the  JFSOCC,  places  liaison  officers 
where  required  with  the  JFACC  and/or  JFC  staff  as  appropriate  within  service 
component  02  facilities  and  operations  centers.  The  SOLE  coordinates  during 
development  of  the  ATO  to  reconcile  duplicate  targeting,  resolve  airspace 
deconfliction,  and  prevent  fratricide  of  SOF  contingents  spread  across 
the  battlefield. 

Naval  SOF  assigned  to  the  JFSOCC  are  normally  under  the  02  of 
a  Naval  Special  Warfare  Task  Group  (NSWTG)  or  Naval  Special  Warfare  Task 
Unit  (NSWTU).  The  NSWTG  is  a  naval  special  warfare  organization  that  plans, 
conducts,  and  supports  SO  in  support  of  fleet  commanders  and  JFSOCCs  (or 
JSOTF  commanders).  The  NSWTU  is  a  subordinate  unit  of  a  NSWTG. 

The  Special  Operations  Coordination  Element  (SOCOORD)  serves 
as  the  primary  advisor  to  an  Army  corps  or  MEF  commander  with  regard  to  SOF 
integration,  capabilities,  and  limitations.  The  SOCOORD  is  a  functional  staff 

element  of  the  corps  (or  MEF)  operations  officer  (G-3)  and  serves  as  the  J-3  SO 
advisor,  with  augmentation,  if  the  corps  (or  MEF)  is  established  as  a  JTF. 

2.1. 3.6  Summary  of  Existing  Fire  Support  Organizations 

Each  of  the  services  has  tailored  its  own  organizations,  personnel, 
and  systems/equipment  to  aid  them  in  prosecuting  targets.  This  has  resulted  in 
duplicate  systems  and  agencies.  In  many  instances,  direct  comparisons 
between  organizations  can  be  made  both  in  terms  of  capabilities  and  span  of 
control.  Additionally,  the  diversity  of  these  systems  and  organizations  has 
created  personnel  training  requirements  that  are  different  but  parallel.  The 
understanding  that  an  Army  FS  Cell  is  functionally  comparable  to  a  Marine  Corps 
FSCC  would  come  easily  to  all  involved.  However,  in  some  areas,  like  in  C2 
systems  of  record  and  favored  fires  support  systems,  the  differences  are 
designed  into  the  system  and  much  harder  to  reconcile.  For  example,  if  each 
service  uses  different  information  systems  to  maintain  their  C2  common 
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operating  picture,  no  one  can  be  certain  that  decisions  made  across  the  services 
have  comparable  quality.  Even  if  the  input  data  to  these  systems  is  identical,  the 
different  presentations  and  functions  may  not  permit  comparable  analysis  by  the 
decision  makers.  The  growth  of  unmanned  systems,  especially  unmanned 
vehicles,  continues  to  complicate  these  C2  systems  further.  A  comparison  of  the 
C2  differences  between  the  services  is  illustrated  in  Table  2. 
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Air  Force 

Army 

Marine  Corps 

Navy 

Fielded  Personnel 

Forward  Air 
Controller  (FAC), 
Forward  Air 

Controller  - 
Airborne  (FAC-A), 
Tactical  Air  Control 
Party  (TACP) 

Fire  Support  Officer 
(FSO),  Forward 
Observer  (FO),  Air 
Liaison  Officer 
(ALO) 

Shore  Fire 
Coordination  Party 
(SFCP),  Tactical  Air 
Control  Party 
(TACP) 

Forward  Air 
Controller  (FAC), 
Forward  Air 

Controller  - 
Airborne  (FAC-A), 
Navy  Ground 

Liaison  Officer 
(NGLO) 

Ground 
Organizations 
(Mortar  /  Artillery 
type  fires) 

Fires  Support  Team 
(FIST),  Fire  Support 
Cell  (FS  Cell),  Fire 
Support 
Coordination 

Center  (FSCC) 

Fire  Support 
Element  (FSE),  Fire 
Support 
Coordination 

Center  (FSCC), 
Forced  Fires 

Coordination 

Center  (FFCC), 
Supporting  Arms 
Coordination 

Center  (SACO 

Supporting  Arms 
Coordination 

Center  (SACC),  Air 
and  Naval  Gunfire 
Liaison  Company 
(ANGLICO) 

Air  Organizations 

Air  Support 
Operations  Center 
(ASOC),  Air 
Operations  Center 
(AOC) 

Fire  Support 
Coordination 

Center  (FSCC), 
Battlefield 

Coordination 
Detachment  (BCD) 

Tactical  Air  Control 
Center  (TACC) 

Direct  Air  Support 
Center  (DASC), 
Tactical  Air  Control 
Center  (TACC) 

Others 

Special  Operations 
Liaison  Officer 
(SOLE) 

Ground  Liaison 
Officer  (GLO) 

Marine  Air  Liaison 
Officer  (MARLO) 

Navy  and 
Amphibious 

Liaison  Officer 
(NALE) 

C2  Systems  of 
Record 

Global  Command 
and  Control  System 
(GCCS)  and 

Theater  Battle 
Management  Corps 
System  (TBMCS) 

Command  Post  of 
the  Future  (CPOF) 

Command  and 
Control,  Personal 
Computer  (C2PC) 

Global  Command 
and  Control  System 
-  Maritime  (GCCS- 
M) 

Fires  Support 
System 

See  JFIT  capability 
matrix 

(Appendix  A) 

Target  Location, 
Designation,  and 
Hand-off  System 
(TLDHS),  Advanced 
Field  Artillery 
Tactical  Data 

System  (AFATDS) 

Target  Location, 
Designation,  and 
Hand-off  System 
(TLDHS),  Advanced 
Field  Artillery 
Tactical  Data 

System  (AFATDS) 

Naval  Fires  Control 
System  (NFCS) 

Table  2:  Parallel  Organizational  Structures 


2.2  CURRENT  FIRE  SUPPORT  REQUEST  SYSTEM 


Within  the  organizational  structure  of  these  units  there  are  processes  and 
methodologies  for  requesting  fire  support.  There  are  currently  three  basic 
categories  of  fire  support  request  systems  in  the  DoD:  Land-Based  Indirect  Fire 
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Support,  Naval  Fires  Support,  and  Close  Air  Support.  Each  of  these  categories 
utilizes  a  different  fire  support  request  system  or  method  and  often  has  service- 
specific  differences  within  each  functional  category. 

Land-based  Indirect  Fire  Support  is  lethal  or  nonlethal  fires  that  are 
provided  to  a  forward  element  from  an  artillery  or  rocket  battery  within  weapons 
range.  For  the  purposes  of  this  study,  this  fire  support  comes  from  another  unit 
and  does  not  include  indirect  fire  systems  that  are  organic  to  the  requesting  unit, 
such  as  mortars.  Land-Based  Indirect  Fire  Support  is  discussed  in  further  detail 
in  Section  2.2.1. 

Naval  Fires  Support  is  lethal  or  nonlethal  fire  support  provided  to  a  forward 
element  by  a  naval  vessel.  This  category  of  fires  typically  encompasses  naval 
gunfire  from  surface  ships,  but  can  also  include  missiles  launched  from 
subsurface  assets.  It  does  not  include  naval  aviation  strike  assets.  Naval  Fire 
Support  is  described  in  further  detail  in  Section  2.2.2. 

Close  Air  Support  is  fire  support  from  the  air  by  fixed  and  rotary-wing 
aircraft  against  targets  in  such  close  proximity  to  friendly  forces  that  detailed 
integration  with  the  fire  and  movement  of  those  forces  is  required.  CAS  is 
currently  being  employed  by  all  service  components,  although  Army  doctrine 
refers  to  it  as  “Close  Combat  Attack”  instead  of  CAS.^®  CAS  request  systems 
also  vary  between  services.  CAS  is  described  in  detail  in  Section  2.2.3. 

Each  of  these  individual  fire  support  request  systems  has  been  doctrinally 
established  to  work  independently  of  the  others  and  they  do  not  possess  a  robust 
capability  to  interface  with  the  other  systems.  With  few  exceptions,  there  are  no 
established  capabilities  to  redirect  a  request  to  another  fire  support  category  if  for 
some  reason  it  cannot  be  fulfilled  by  the  requested  method.  These  request 
systems  are  isolated  in  both  communications  and  organizational  pathways. 
Complicating  the  situation,  the  service  components  are  not  doctrinally  obligated 
to  provide  support  equally  to  the  other  services.  Section  2.2.4  describes  the 


T.  Crutchfield,  W.T.  Golden,  IV,  and  T.  Throne,  Jr.,  "Close  Combat  Support," 
[http://www.globalsecurity.org/military/library/report/call/call_00-9_part1  .htm],  Sep  06. 
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challenges  to  the  current  JFS  request  routing  system.  A  simplified  summary  of 


doctrinal  fire  support  roles  and  missions  obligations  is  shown  in  Table  3. 


DOCTRINAL 
ROLES  FOR 
FIRE  SUPPORT 

Army  provides 

Fire  Support  to: 

Navy  Provides 
Fire  Support  to: 

Air  Force 

Provides  Fire 
Support  to: 

Marine  Corps 

Provides  Fire 
Support  to: 

SUPPORTED  UNIT 

Army 

Army 

Collateral 

Support 

Primary  Mission 

Collateral 

Support 

Navy 

No  Doctrine 

Navy 

Collateral 

Support 

Primary  Mission 

Air  Force 

Collateral 

Support 

No  Doctrine 

Air  Force 

No  Doctrine 

Marine  Corps 

Collateral 

Support 

Primary  Mission 

Collateral 

Support 

Marine  Corps 

SOF 

Primary  Mission 

Primary  Mission 

Primary  Mission 

Primary  Mission 

Table  3:  Summary  of  Service  Doctrinal  Obligations  for  Fire  Support 


2.2.1  Land-Based  Indirect  Fire  Support 

In  land  warfare,  the  generation  of  maximum  combat  power  results  from 

the  most  efficient  use  of  firepower.  Firepower  is  defined  as  the  battlefield  effects 

produced  by  all  weapons  and  attack  systems  available  to  the  force  commander. 

Many  of  these  weapons  and  attack  systems  are  in  the  category  of  land-based 

indirect  fire  support.  Army  Field  Manual  6-20  describes  fire  support  as  follows: 

Indirect  fire  support  is  the  collective  and  coordinated  use  of  land- 
based  indirect-fire  weapons,  and  other  lethal  and  nonlethal  means 
in  support  of  a  battle  plan.  Fire  support  includes  mortars,  field 
artillery,  air  defense  artillery  in  secondary  mission,  and  air-delivered 
weapons.  Nonlethal  means  are  EW  capabilities  of  military 
intelligence  organizations,  illumination,  and  smoke.  The  force 
commander  employs  these  means  to  support  his  scheme  of 
maneuver,  to  mass  firepower,  and  to  delay,  disrupt,  or  destroy 
enemy  forces  in  depth.  Fire  support  planning  and  coordination  exist 
at  all  echelons  of  maneuver.  Fire  support  destroys,  neutralizes,  and 
suppresses  enemy  weapons,  enemy  formations  or  facilities,  and 
fires  from  the  enemy  rear  area.  In  most  land-based  large-scale 
conflict,  fire  support  systems  such  as  field  artillery  or  mortars  could 
be  the  principal  means  of  destroying  enemy  forces.^® 


^  Department  of  the  Army,  Fire  Support  in  The  Airiand  Battie,  Field  Manual  6-20,  May  1988, 

p.  1-2. 
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A  typical  unplanned  request  for  Army  artillery  support  from  an  Army  unit 
should  follow  the  chains  of  command  and  communication  as  detailed  below  and 
shown  in  Figure  12. 


Figure  12:  Typical  Request  Routing  for  Army  Unplanned  Artillery  Support 


A  soldier  alerts  the  company  FIST  team  of  a  target.  A  TLDHS  is  used  to 
accurately  fix  the  target  position.  The  TLDHS  data  is  transferred  into  AFATDS 
and  additional  target  information  is  added  as  required.  The  AFATDS  file  is 
transmitted  up  the  organizational  chain  of  command  via  a  radio  network  (EPLRS, 
JTRS,  or  other).  The  AFATDS  file  is  reviewed  within  the  battalion,  brigade,  and 
division  as  required.  At  the  brigade  level  and  higher,  C2  information  from  the 
CPOF  system  is  also  reviewed.  The  FSCOORD  within  the  division  FS  Cell 
determines  which  artillery  battery  should  provide  support  and  assigns 
the  tasking. 

At  this  point,  the  artillery  battery  receives  the  AFATDS  file  for  action  and 
other  organizations,  like  the  BCD  or  involved  FS  Cells,  also  can  review  the 
updated  file  for  their  information.  Up  to  this  point,  the  target  data  has  remained  in 
the  AFATDS  system  and  has  been  transmitted  via  radio  networks.  However, 
within  the  artillery  battery’s  Fire  Direction  Center,  key  data  from  the  AFATDS  file 
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(i.e.  target  coordinates,  etc)  are  now  re-entered  into  the  artillery  control  system. 
Additionally,  the  artillery  battery  must  now  make  voice  contact  with  the  originating 
FIST  team  to  coordinate  the  fire  mission.  Voice  communications  confirm  the 


firing  solutions  and  ordnance  type,  etc.  This  process  is  described  in  Figure  13. 


For  planned  fires,  this  organizational  construct  may  be  tailored  to  a  more 
direct  connection  from  the  FIST  or  FS  Cell  to  the  artillery  battery.  However,  for 
unplanned  fire  support,  coordination  through  the  division  FS  Cell  and  FSCOORD 
are  required.  In  any  event,  even  in  the  more  complicated  case,  decision  making 
is  completed  at  a  maximum  of  the  0-5  level  and  the  majority  of  the  steps  are 
completed  within  the  AFATDS  system. 


Department  of  the  Army,  Tactics,  Techniques,  and  Procedures  for  Observed  Fire,  Field 
Manual  6-30,  July  1991. 
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2.2.2  Naval  Fire  Support 

Naval  Fire  Support  includes  all  weapons,  other  than  naval  aircraft,  that  are 
launched  from  the  maritime  environment.  This  includes  naval  gunfire  from 
surface  ships  and  missile  fires  from  surface  and  subsurface  ships.  Naval  guns 
are  employed  from  cruisers  (CG-47  class  with  two  5-inch  guns)  and  destroyers 
(DDG-51  with  one  5-inch  gun;  and  DD-1000  with  two  155  mm  or  5-inch  guns 
planned).  Tomahawk  Land-Attack  cruise  Missiles  (TLAM)  can  be  launched  from 
cruisers,  destroyers,  and  submarines,  depending  on  loaded  inventories. 

Employment  of  naval  fires  support  currently  requires  a  qualified  forward 
observer  team  (FO)  ashore  to  propose  a  target  to  the  applicable  Fire  Support 
Element  (FSE).  This  request  is  forwarded  up  the  chain  of  command  (Marine 
Corps)  to  the  senior  FSE  known  as  the  shore  based  Fire  Support  Coordination 
Center  (FSCC).  A  Forced  Fire  Coordination  Center  (FFCC)  may  also  exist  at  the 
MAGTF/MEF  level. 

The  FFCC  directs  both  the  TACC  (for  air  support)  and  regiment  or 
battalion  FSE  (for  artillery  and  naval  guns).  To  provide  naval  gun  fire  support, 
the  FFCC  contacts  the  navy  Supporting  Arms  Coordination  Center  (SACC)  to 
have  a  ship  tasked  for  support  of  the  request.  The  ship  is  assigned  to  support 
the  requesting  FO  either  for  a  single  mission,  a  designated  period  of  time,  or  until 
further  notice.  The  ship  then  establishes  radio  communication  with  the  FO  and 
provides  fire  support  as  requested.  When  an  FSCC  is  not  established  ashore, 
the  forward  observers  report  directly  to  the  SACC.  Ships  will  then  typically  be 
pre-assigned  as  gun  fire  support  units  and  will  be  available  for  tasking  by 
designated  FO. 

TLAM  employment  is  directed  by  the  Commander,  Joint  Task  Force 
(CJTF)  strike  cell.  A  formalized  record  message  exchange,  along  with  mission 
plans  are  sent  to  the  ship  and  the  weapons  are  employed  as  directed. 
Employment  of  tactical  Tomahawk  missiles  is  expected  to  be  ordered  by  the 
CJTF  to  the  JFMCC  then  the  ship  or  submarine.  The  initial  request  for  fires 
would  come  from  the  forward  observer,  be  validated  at  the  CJTF  level  then 
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tasked.  If  release  authority  and  mission  planning  software  was  available  to  the 
SACC  (or  firing  unit),  the  communication  flow  would  follow  that  used  for 
naval  gunfire. 

Current  employment  of  naval  guns  in  a  fire  support  role  closely  resembles 
the  employment  of  artillery.  A  qualified  forward  observer  establishes  and 
authenticates  radio  contact  on  a  specified  frequency  with  the  pre-designated  fire 
support  ship.  Calls  for  fire  are  passed  via  voice  to  the  ship  and  repeated  back  to 
the  observer  to  ensure  that  they  were  correctly  understood.  The  coordinates  are 
entered  into  the  gun  weapon  system  aboard  the  ship,  which  calculates  aiming 
parameters,  and  spotting  round(s)  are  shot.  Corrections  from  the  impact  of  the 
spotting  round(s)  are  passed  by  voice  from  the  forward  observer  and  additional 
spotting  shots,  if  required,  are  made  until  the  aim  point  is  correct.  The  target  is 
then  engaged  with  the  requested  volume  and  type  of  fire. 

Errors  in  initial  round  impact  stem  from  a  variety  of  sources.  Position  error 
of  both  the  ship  and  forward  observer  even  with  GPS  can  be  several  meters. 
Accuracy  of  the  map  in  regards  to  the  datum  used  will  also  introduce  errors  in 
positioning.  Aerodynamic  effects  on  the  round,  especially  at  longer  ranges 
achieved  by  the  new  Extended  Range  Guided  Munitions  (ERGM)  may  not  be 
consistent  throughout  the  fires  mission  and  cannot  be  perfectly  evaluated  prior  to 
shooting.  Precision  in  the  quality  of  the  target  position  is  inherently  difficult  due 
to  equipment  limitations.  Laser  range  finder  accuracy  in  range  determination  is 
very  good,  but  the  lack  of  portable  laser  ring  gyroscopes  limits  bearing  accuracy 
to  that  obtainable  by  a  digital  magnetic  compass.  These  errors  combine  to 
produce  a  “danger  close”  range  of  750  meters  which  require  direct 
communication  between  the  firing  ship  and  forward  observer  to  “walk”  the 
spotting  rounds  onto  the  target.^^ 

The  installation  of  the  Mk  160  5-inch/62  caliber  upgraded  gun  weapon 
system  on  cruisers  and  destroyers,  along  with  the  automated  Naval  Fires  Control 
System  (MFCS)  provides  a  digital  interface  from  the  forward  observer  to  the 


Department  of  the  Army,  Tactics,  Techniques,  and  Procedures  for  Observed  Fire, 
Field  Manual  6-30,  July  1991,  p.  4-4. 
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SACC  and  fire  support  ships.  MFCS  receives  and  processes  digital  data 
requests  from  various  USMC  fire  support  systems  via  radio  frequency  data  links 
from  a  Military  Ruggedized  Tablet  (MRT)  or  Personal  Digital  Assistant  (PDA)- 
based  system  via  AFATDS  or  directly  depending  upon  specific  system 
configuration.  Fire  missions  are  planned  within  MFCS  and  tasked  to  the  support 
ships.  MFCS  also  displays  a  common  operational  picture  of  the  littoral  area  of 
operations  and  highlights  conflicts  of  air,  sea,  and  land  assets  with  respect  to 
fires  response. 

MFCS  is  used  along  with  AFATDS  and  Command  and  Control  Personal 
Computer  (C2PC)  to  maintain  a  coherent  operational  picture  of  the  battlespace. 
Transfer  of  data  between  these  systems  is  transitioning  to  a  fully  automated 
digital  information  exchange.  Data  link  information  is  also  received  from  USAF 
Theater  Battle  Management  Core  System  (TBMCS)  Air  Tasking  Orders  and  Air 
Control  Orders.  MFCS  displays  conflicts  with  air  assets  along  the  5-inch 
projectile  flight  path,  but  these  displays  are  dependant  upon  the  quality  of  the 
inputs  for  aircraft  positions  from  these  other  systems  and  operator  interaction. 
One  advantage  of  naval  surface  fires  is  the  ability  to  reposition  the  firing  ship. 
This  action  may  allow  for  a  suitable  gun-target  line  to  resolve  airspace  conflicts. 

Another  Naval  Fire  Support  weapon  is  the  Tomahawk.  Improved  TLAMs 
and  the  Tactical  Tomahawk  variants  are  both  expected  to  be  in  the  inventory  in 
2020.  Currently,  TLAM  missions  are  designed  by  planning  system  detachments, 
either  land-based  or  afloat  on  the  carrier.  The  mission  data  is  then  sent  to  the 
shooter  (surface  ship  or  submarine)  via  tactical  data  link  along  with  the  tasking 
and  authority  to  fire.  Ship’s  company  plots  the  missile  flight  path  to  the  first  pre¬ 
planned  waypoint,  ensuring  the  missile  is  deconflicted  with  nearby  air  and  naval 
traffic,  and  fires  the  TLAM.  Planned  improvements  in  the  Tomahawk  Afloat 
Planning  System  (TAPS)  will  allow  the  battle  group  commander  to  plan  or  modify 
TLAM  missions  while  at  sea.^^ 

G.  T.  Kollar,  “Naval  Fire  Control  System,”  Field  Artillery,  March/April  2005. 

Federation  of  American  Scientists,  “MK  37  TOMAHAWK  Weapon  System  (TWS),  Afloat 
Planning  System  (APS),  Theater  Mission  Planning  Center  (TMPC),”  [http://www.fas.orq/man/dod- 
101/svs/ship/weaps/tmpc-aps.html.  Oct  06. 
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“Tactical  Tomahawk  has  the  capability  to  be  reprogrammed  in-flight  to 
strike  any  of  15  preprogrammed  alternate  targets  or  redirect  the  missile  to  any 
Global  Positioning  System  (GPS)  target  coordinates”.^"^  This  capability  for  GPS 
targeting  allows  for  rapid  mission  planning  to  be  conducted  by  the  firing  unit 
(CG/DDG/SS(G)N)  as  a  potential  time  sensitive  fire  support  response.  While  this 
planning  and  re-tasking  option  will  reduce  the  time  required  for  response,  the 
TLAM  as  a  weapon  is  not  well-suited  for  un-planned  targets.  One  reason  for  this 
is  the  subsonic  fly-out  of  the  TLAM  that  limits  response  time,  especially  for  long 
range  targets.  Although  the  range  of  a  TLAM  is  nearly  1000  miles,  at  600  mph 
only  targets  within  100  miles  could  be  reached  within  10  minutes.  “Tactical 
Tomahawk  will  have  a  limited  capability  against  time-sensitive  targets.  Unlike  an 
armed  unmanned  aerial  vehicle  or  the  unmanned  combat  aerial  vehicle.  Tactical 
Tomahawk  cannot  be  recalled,  and  its  ability  to  loiter  over  the  battlefield  is  limited 
by  its  relatively  short  endurance. 

In  a  typical  request  for  Naval  Surface  Fires  from  an  ashore  Marine  Corps 
combat  element  should  follow  the  chains  of  command  and  communication  as 
shown  in  Figure  14. 


^  Federation  of  American  Scientists,  “BGM-109  Tomahawk,”  [http://www.fas.orq/man/dod- 
101/svs/smart/bqm-1 09.html.  Oct  06. 

S.  Morrow,  “What  Comes  after  Tomahawk?,”  Proceedings,  retrieved  on  October  2,  2006, 
from  www.usni.orq/Proceedinqs/Articles03/PROmorrow07-2.htm.  July  2003. 
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Figure  14:  Marine  Requests  for  Artillery  or  CAS 


The  Marine  Corps  GCE  uses  a  TLDHS  to  accurately  fix  the  target  position. 
As  before,  the  TLDHS  data  is  transferred  into  AFATDS  where  additional  target 
information  is  added  as  required.  The  AFATDS  file  is  transmitted  up  the  chain  of 
command  to  the  battalion,  regiment,  and  division  FSEs,  the  FSCC,  and/or  the 
FFCC  via  a  radio  network  (EPLRS,  JTRS,  or  other).  At  the  FFCC,  for  a  Marine 
Corps-only  scenario,  C2  information  from  the  C2PC  system  is  also  reviewed.  If 
this  fires  request  will  involve  naval  surface  fires,  C2  information  from  GCSS-M  is 
also  considered. 

For  the  case  where  Marine  Corps  mortars/artillery  will  support,  the  FFCC 
director  tasks  the  appropriate  providing  battery.  Again,  while  the  AFATDS  file  is 
forwarded  to  the  providing  battery,  key  targeting  data  is  re-entered  into  the 
artillery  weapon  control  systems.  Also,  a  voice  link  from  the  providing  battery  to 
a  forward  observer  (usually  in  the  originating  FSE)  is  established  to  coordinate 
the  fire  mission. 

For  the  case  where  Naval  Surface  fires  will  support,  the  FFCC  must 
interface  with  the  SACC.  At  this  point,  the  original  AFATDS  request  is  re-entered 
into  MFCS.  GCSS-M  is  also  reviewed.  Once  the  SACC  decides  on  a  course  of 
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action  for  potential  NSF  support,  leadership  for  the  MAGTF,  CATF,  and  or  CTF 
must  be  notified  (also  known  as  the  Supported  and  Supporting  commanders  in 
some  theaters).  A  tasking  message  for  the  Commander  of  the  providing  ship  is 
generated  and  the  MFCS  targeting  information  is  passed  to  that  ship  via  standard 
ship-to-ship  communication  networks.  The  providing  ship  makes  voice  contact 
with  a  FO  within  the  requesting  organization  to  direct  fires.  The  CAS  case  will  be 
described  in  the  following  section. 

In  the  Marine-supporting-Marine  example,  decision  making  is  completed 
at  a  maximum  of  the  0-5  level  and  the  majority  of  the  steps  are  completed  within 
the  AFATDS  system.  However,  in  order  to  get  support  from  the  Navy,  the  level 
of  leadership  complexity  increases  to  the  0-7  level  with  a  corresponding  number 
of  extra  steps.  From  a  communications/networking  perspective,  re-entering  the 
data  into  MFCS  and  the  integration  of  a  separate  C2  system,  GCCS-M,  is 
problematic.  It  is  unlikely  that  a  Marine  FO,  using  his  AFATDS  system,  will  be 
completely  in  synch  with  the  providing  ship,  using  its  MFCS  system.  So  the 
coordination  step  requires  comprehensive  voice  communications  support,  which 
is  often  difficult  for  ship-to-shore  message  traffic.  The  same  dilemma  is  posed  by 
using  different  C2  “systems  of  record”  which,  by  definition,  display 
information  differently. 

2.2.3  Close  Air  Support 

According  to  Joint  Pub  3-09.3,  “CAS  is  air  action  by  fixed-  and  rotary-wing 
aircraft  against  hostile  targets  that  are  in  close  proximity  to  friendly  forces  and 
that  require  detailed  integration  of  each  air  mission  with  the  fire  and  movement  of 
those  forces.”^®  CAS  includes  a  variety  of  weapons  delivered  from  Air  Force, 
Navy,  and  Marine  Corps  aircraft.  These  weapons  include  guided  and  unguided 
bombs,  rockets,  and  missiles  as  well  as  nonkinetic  effects  delivered  by  aircraft. 
CAS  effects  on  the  target  vary  dramatically  according  to  the  weapons  employed 
and  the  platform  that  employs  them. 


Department  of  Defense,  Joint  Tactics,  Techniques,  and  Procedures  for  dose  Air  Support 
(CAS),  Joint  Publication  3-09.3,  Change  1, 2  September  2005,  p.  GL-7. 
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Close  Air  Support  engagements  are  inherently  difficult  to  perform  well  due 

to  coordination  and  integration  challenges.  This  employment  difficulty  stems 

from  several  sources,  including  the  physical  differences  between  the  land  and  air 

environments,  the  contrasts  in  equipment  speeds,  and  the  communications 

challenges  between  these  two  settings.  These  are  some  of  the  many  reasons 

why  CAS  employment  typically  requires  a  qualified  FAC  or  JTAC  who  is 

intimately  familiar  with  the  supported  friendly  force  status  and  intent.  The  JTAC 

and  the  TACP,  which  the  JTAC  is  a  part  of,  is  the  ground  commander’s  sole 

conduit  to  CAS  fires  and  the  primary  mechanism  he  uses  to  maximize  the 

employment  of  CAS.  Joint  Pub  3-09.3  describes  the  commander’s 

responsibilities  for  CAS  employment: 

CAS  is  an  element  of  joint  fire  support.  Synchronizing  CAS  in  time, 
space,  and  purpose  with  supported  maneuver  forces  increases  the 
effectiveness  of  the  joint  force... The  supported  commander 
establishes  the  priority,  timing,  and  effects  of  CAS  fires  within  the 
boundaries  of  the  land,  maritime,  SOF,  or  amphibious  force’s  area 
of  operations.^^ 

The  “synchronization”  of  CAS  in  time  and  space  with  other  fires  is  an  art 
that  requires  training,  practice,  and  understanding  of  the  ground  situation 
and  intent. 

CAS  requests  can  be  divided  into  two  categories:  planned  CAS  and 
immediate  CAS.  Planned  CAS  is  typically  requested  to  support  offensive 
operations  or  as  a  preventative  measure  based  on  anticipated  target 
opportunities.  Immediate  CAS  requests  are  reactive  by  nature  and  are 
unplanned  but  too  urgent  to  wait  for  tasking  via  the  day-long  ATO  cycle. 
Whether  tasked  via  a  preplanned  or  immediate  request,  there  are  typically  CAS 
assets  available  or  “on-call”  to  strike  evolving  targets.  The  concept  of  “Push 
CAS,”  where  CAS  aircraft  are  launched  to  an  on-call  mission  in  anticipation  of  an 
immediate  CAS  request,  was  used  extensively  in  Operation  Iraqi  Freedom  but  its 
successful  application  is  reliant  on  an  abundance  of  CAS  assets. 


Department  of  Defense,  Joint  Tactics,  Techniques,  and  Procedures  for  dose  Air  Support 
(CAS),  Joint  Publication  3-09.3,  Change  1, 2  September  2005,  p.  1-1. 
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In  a  typical  immediate  request  for  CAS,  the  ground  commander  will  have 
to  first  decide  to  request  CAS  in  lieu  of  or  in  addition  to  other  fire  support.  Upon 
making  the  decision  to  request  CAS  against  a  target,  the  commander  instructs 
his  TACP  to  send  a  request  via  the  AFARN  (Army  request)  or  the  TARN  (Marine 
request).  The  critical  request  information  is  compiled  by  the  TACP  onto  Section  I 
of  the  DD  Form  1972,  Joint  Tactical  Air  Strike  Request,  and  sent  via  voice  over 
the  AFARN  to  the  ASOC,  or  over  the  TARN  to  the  DASC.  The  portion  of  the 
target  and  engagement  data  in  block  8  of  the  DD  Form  1972  is  commonly 
referred  to  as  the  “9-line.”  Figure  15  shows  a  sample  of  the  DD  Form  1972. 
(Note:  There  are  actually  21  different  versions  of  the  9-line.  Please  see 
Appendix  B  for  an  explanation  of  data  formats.) 
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See  Joint  Pub  3-09.3  for  preparation  instructions. 
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Figure  15:  DD  Form  1972,  Joint  Tactical  Air  Strike  Request  (From 


Department  of  Defense,  Joint  Tactics,  Techniques,  and  Procedures  for  Close  Air  Support 
(CAS),  Joint  Publication  3-09.3,  2  September  2005,  pp.  B-5. 
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When  the  request  is  received  at  the  ASOC  or  DASC,  it  is  aligned  with  one 
of  the  available  CAS  providers  available.  The  ASOC  typically  only  has  Air  Force 
aircraft  available  for  tasking  and  the  DASC  typically  only  has  Navy  and  Marine 
aircraft  available  for  tasking.  In  practice,  if  either  the  ASOC  or  the  DASC  do  not 
have  enough  CAS  providers  to  fulfill  their  requests  they  contact  the  other  to 
attempt  to  pass  target  requests. 

As  the  CAS  request  system  exists  today,  there  is  very  little,  if  any, 
consideration  given  to  the  synchronization  of  CAS  providers  and  desired  effects. 
The  immediate  CAS  requests  are  sent  to  the  ASOC  or  DASC  and  an  available 
asset  is  assigned  to  fulfill  each  request.  These  pairings  are  completed  in  a  more 
or  less  “first  come,  first  serve”  manner  with  only  some  consideration  given  to 
urgency  of  the  request  (“troops  in  contact”  requests  are  given  priority). 

The  target  tasking  orders  that  fulfill  the  requests  are  then  passed  to  the 
CAS  aircraft  via  a  UHF/VHF  voice  transmission.  Once  the  aircraft  arrive  near  the 
target  area,  they  contact  the  JTAC  directly  via  UHF/VHF  radio.  The  JTAC 
provides  the  CAS  aircraft  with  a  brief  description  of  the  ground  situation,  the 
known  or  suspected  anti-aircraft  threats,  and  describes  any  deconfliction 
measures  in  place  to  protect  the  fire  support  providers  (separating  the  aircraft 
from  other  aircraft  or  ballistic  fires  like  artillery).  The  JTAC  then  verbally  or 
digitally  passes  the  target  data  to  the  CAS  aircraft  using  the  “9-line”  format  or 
derivative.  Once  the  CAS  provider  has  the  required  information  and  a  situational 
awareness  of  the  engagement  area,  the  JTAC  will  then  typically  send  a  verbal 
description  of  the  target  to  the  aircraft  to  aid  in  acquisition  of  the  target  during  the 
attack.  Once  the  attack  begins,  the  JTAC  or  FAC  will  give  final  weapons  release 
approval  to  the  CAS  aircraft  only  when  he  is  satisfied  that  the  aircraft  is  attacking 
the  intended  target.  Because  of  the  amount  of  coordination  involved  to  execute  a 
CAS  engagement,  it  typically  takes  at  least  10  minutes  from  first  radio  contact 
with  the  aircraft  to  weapons  impact  on  the  first  target  in  the  area.  Subsequent 
target  attacks  in  the  vicinity  take  less  time.  A  typical  Army  request  for  Air  Force 
CAS  support  should  follow  the  chains  of  command  and  communication  as 
detailed  below  and  shown  in  Figure  16. 
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Figure  16:  Army  Request  Routing  for  Artillery  or  AF  CAS 


A  soldier  alerts  the  company  FIST  of  a  target.  Again,  a  TLDHS  is  used  to 
fix  the  target  position  and  the  data  is  routed  up  the  chain  of  command  via  the 
AFATDS  system  and  the  radio  networks.  At  one  of  the  command  levels  up 
through  the  BCD,  based  on  the  target  characteristics,  permission  is  given  to  a 
FO,  FAC,  TACP,  or  JTAC  to  contact  the  ASOC  to  request  Air  Force  CAS 
support.  At  this  point,  the  AFATDS  file  is  manually  transcribed  into  the  “9-line” 
request  format  and  read  to  the  ASOC.  The  ASOC  (within  the  AOC)  considers 
the  resources  it  has  under  its  control  and  the  C2  operational  picture  as  presented 
by  TBMCS  (or  GCCS).  It  makes  a  decision  to  task  one  of  its  assets  and  makes  a 
voice  connection  to  that  platform  via  one  of  many  possible  communications 
routes.  (The  complexity  of  aircraft  communications  and  data  links  is  shown  in 
Appendix  A,  JFIIT  Interoperability  assessment  matrix.) 

The  ASOC  may  pass  part  or  all  of  the  “9-line”  data  to  the  tasked  platform 
with  instructions  to  contact  the  originating  FAC,  TACP,  or  JTAC.  The  aircraft 
commander  will  confirm  “9-line”  data,  coordinate  with  the  FAC  or  JTAC,  and 
complete  the  engagement. 
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While  it  has  been  technically  demonstrated  that  AFATDS  data  can  be 
passed  to  specifically  configured  aircraft  and  presented  in  the  cockpit  via 
particular  data  links  and  special  on-board  systems,  this  capability  is  not  high 
priority  for  the  services  as  it  could  not  be  generally  applied  across  an  aircraft  fleet 
with  divergent  communication  link  and  on-board  system  baselines.  Continued 
translation  to  a  verbal  9-line  format  is  far  more  likely. 

2.2.4  Challenges  of  a  Joint  Fire  Support  Request 

The  examples  above  outline  the  basic  chains  of  command  and 
communication  for  fires  support  requests.  The  environment  becomes 
significantly  more  complicated  when  non-standard  service  pairings  are 
considered.  The  example  in  Figure  17  illustrates  the  coordination  and  decision 
making  complexity  within  a  Marine  request  for  JFS  from  providers  outside  of 
standard  request  channels. 
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Figure  17:  Coordination  and  Decision  Making  Complexity  of  JFS 

The  Project  Team  approached  this  analysis  from  the  perspective  of 
standard,  published  organizational  constructs  that  preserve  standard  operational, 
tactical,  and  administrative  lines  of  control.  This  was  done  for  two  primary 
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reasons.  First,  it  allowed  decision-making  to  be  completed  within  the  boundaries 
of  fielded  systems  and  current  training  methods.  It  also  allowed  system  failures 
to  be  traced  back  to  the  appropriate  level  of  command  within  the  owning  service. 

The  team  concedes  that  there  are  probably  an  infinite  number  of  ways  to 
assemble  an  organizational  structure  if  different  assumptions  are  applied.  For 
example,  a  capabilities-based  construct  could  be  used  to  greatly  simplify  the 
overhead  associated  with  chains  of  command.  However,  that  construct  would 
assume  perfect  interoperability  of  all  underlying  systems.  The  team  deemed  an 
approach  like  this  one  as  more  risky  than  the  one  chosen. 

Coordination  and  decision  making  complexity  examples  are  shown  in 
Appendix  C.  Networking  and  automated  information  system  complexity  is 
evaluated  in  Section  4.3.1.  Conclusions  from  these  diagrams  may  be  found  in 
the  metrics  summary  table  in  Section  2.6. 

2.3  FUNCTIONAL  ARCHITECTURE 

The  SEDP  (as  described  in  Section  1.3)  transforms  the  stakeholders’ 
requirements  and  needs  into  a  set  of  system  functions  and  process  descriptions 
that  generate  information  for  decision  makers  and  provide  input  for  the  next  level 
of  functional  development.  These  system  functions  and  process  descriptions 
also  form  a  “blueprint”  of  what  the  system  needs  to  do  and  what  performance 
criteria  are  used  for  assessment  of  alternative  solutions.  This  set  of  artifacts 
forms  the  functional  architecture. 

Many  Systems  Engineering  experts  refer  to  this  process  as  a  functional 
analysis.  According  to  Blanchard  and  Fabrycky,  a  function  is  “a  specific  or 
discrete  action  (or  series  of  actions)  that  is  necessary  to  achieve  a  given 
objective.”^®  The  objective  of  this  analysis  is  to  determine  what  the  system  must 
do  but  not  constrain  the  solution  space  into  how  it  must  be  done. 


2.3.1  Input-Output  Modeling 


B.  S.  Blanchard  W.  J.  Fabrycky,  Systems  Engineering  and  Anaiysis,  4th  ed.,  Pearson 
Prentice  Hall,  2006,  p.  62. 
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The  JFS  system  and  environment  can  be  described  on  the  basis  of  the 
inputs  and  the  outputs  of  the  system,  and  this  Input-Output  model  serves  as  a 
key  artifact  of  the  overall  functional  architecture.  These  system  flows  include 
Controllable  and  Uncontrollable  Inputs  and  Intended  and  By-Product  Outputs. 
The  Input-Output  (1-0)  Model  for  a  fire  support  request  is  critical  to  ensuring  the 
end-product  is  flexible  and  responsive  to  any  operating  environment  in  which  the 
end-product  may  be  used.  The  1-0  Model  was  a  tool  used  by  the  Project  Team 
to  help  scope  and  bound  the  problem. 

The  system  being  proposed  consists  of  a  process  that  accepts  a  valid 
target,  generates  and  transmits  a  tasking  order  to  the  “best  provider”  based  on 
the  current  rules  of  engagement,  commander’s  intent  and  COP.  The  intended 
output  of  the  system  is  secure  tasking  orders  with  an  expectation  of  improved 
timeliness  and  reduced  risk  of  fratricide.  Unintended  results  of  the  system  were 
evaluated  to  include  risk  of  transmission  intercept;  undetected  errors  in  the  fires 
request;  and  uncontrollable  environmental  interference  preventing  transmission 
of  request  or  tasking.  The  process  used  for  determining  the  inputs  and  outputs  is 
described  in  more  detail  in  Appendix  C.  Neither  the  input  nor  the  output  items 


were  prioritized  in  this  modeling  step.  The  resulting  input  and  output  model  is 
described  in  Figure  18. 
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Figure  18:  Input-Output  Model 
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2.3.2  Functional  Decomposition  of  Joint  Fires 

Due  to  the  complexity  of  the  existing  Joint  Fire  Support  system  and  the 
constructs  chosen  thus  far,  a  time-flow  approach  was  taken  to  perform  the  initial 
functional  breakdown.  In  a  general  request  for  fire  support,  the  following  steps 
are  completed: 

•  First,  details  on  a  potential  target  are  collected  by  a  fielded  unit. 

•  Second,  when  a  unit  decides  it  cannot  prosecute  the  target  with  its 
resources,  the  target  details  are  forwarded  to  higher  organizational 
levels  in  some  form  of  Joint  Fire  Support  (JFS)  request. 

•  Third,  at  the  higher  organizational  levels,  a  data  collection  and 
synthesis  occurs.  There  are  organizational  constraints  on  the 
range  of  data  that  can  be  collected  so  the  data  synthesis  that 
results  is  a  function  of  the  data  input.  Steps  two  and  three  can 
happen  repeatedly  until  one  of  the  organizational  levels  has  the 
ability  to  act. 

•  Fourth,  a  decision  and  a  corresponding  action  plan  are  made. 

•  Fifth,  the  decision  and  action  plan  are  disseminated  to  affected 
organizational  levels. 

•  Sixth,  the  involved  organizational  levels  execute  the  action  plan. 

This  functional  flow  is  outlined  in  Figure  19.  The  functional  flow  within  the 

project  design  space  aligns  with  the  Track,  Target,  and  Engage  functions 
described  by  the  F2T2EA  model. 
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Figure  19:  Functional  Flow  Diagram  of  the  System 

These  system  functions  are  multi-faceted  and  inter-related.  This  system’s 
primary  functions  include:  sending  the  JF  request,  processing  the  JF  request 
(which  includes  making  a  decision  based  on  collected  information),  sending  the 
JF  tasking  to  the  provider,  and  receiving  feedback  from  the  provider  that  the 
tasking  was  either  accepted  or  rejected  (reclama).  Additionally,  this  system  must 
have  a  sufficiently  capable  communications  infrastructure  to  transmit  and  receive 
the  necessary  information.  The  following  are  descriptions  of  what  is  involved  in 
each  one  of  these  overarching,  top-level  functions  (see  Appendix  D:  Functional 
Flow  Analysis,  for  a  more  detailed  analysis): 

Send  JF  Request:  This  system  function  involves  the  process  of 
gathering  information  about  the  target,  the  requester,  and  the  desired  effects  on 
the  target.  The  output  of  this  function  is  a  majority  of  the  actionable  information 
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for  the  rest  of  the  system.  (See  Appendix  B  for  more  information  about  fire 
support  request  formats) 

Process  JF  Request:  This  function  involves  gathering  information  from 
other  sources  to  help  decision  makers  develop  a  preferred  course  of  action.  The 
ability  to  pull  data  from  C2  systems  regarding  position  of  Blue/Red  forces,  as  well 
as  other  on-going  operations,  and  link  this  information  with  provider  availability  is 
a  key  component  of  this  function.  This  function  will  also  prioritize  each  request 
within  the  context  of  the  larger  area  of  operations.  It  will  also  provide  a  listing  of 
necessary  actions  to  deconflict  a  particular  fires  provider  with  the  target  area  (i.e. 
avoid  flying  aircraft  through  artillery  landing  zones).  The  output  of  this  function  is 
all  available  information  to  make  a  preferred  requester/provider  pairing.  This 
quality  of  the  output  is  highly  dependent  on  the  source  data.  Based  on  the 
information  available  to  the  appropriate  decision-maker,  a  preferred  course  of 
action  will  be  selected. 

Send  JF  Tasking  to  Provider:  At  this  point,  the  request  along  with 
relevant  additional  information  will  be  transmitted  to  the  fires  provider.  This  may 
be  the  first  time  the  fires  provider  has  been  contacted  regarding  a  particular 
mission,  so  complete  and  accurate  information  transfer  is  important. 

Provider  Accepts/Reclamas  Tasking:  Based  on  the  mission  tasking 
and  current  provider  status,  there  is  an  opportunity  for  a  provider  to  opt  out  of  a 
tasking.  Until  the  designated  fires  provider  accepts  a  tasking  and  coordinates  (as 
required)  with  the  requesting  unit,  the  management  structure  will  continue  to 
track  the  fires  request. 

Communication:  Underlying  these  other  system  functions,  this  system 
requires  communication.  Lack  of  adequate  communications  is  a  primary  failure 
mode  of  this  system  so  it  will  be  tracked  as  a  stand-alone  function. 
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2.3.3  F2T2EA  Functional  Analysis 

The  “Find,  Fix,  Track,  Target,  Engage,  Assess”  kill  chain  forms  the  basis 
of  the  Joint  Fires  chronological  process.  The  target  type  is  an  “unanticipated, 
immediate  target”  that  was  not  planned  to  be  struck  and  needs  to  be  serviced 
outside  of  the  normal  air  tasking  order  planning  cycle."^®  An  analysis  of  the 
functional  sequence  and  the  chronological  order  of  the  functions  provide 
additional  insight  into  the  design  problem.  Additionally,  the  data  that  must  be 
utilized  by  each  of  these  functions  must  be  identified.  The  movement  of  essential 
data  between  functions  is  summarized  in  Figure  20. 

Available  Bandwidth  Control 


Figure  20:  Context  Diagram  of  Functional  and  Data  Flow 

2. 3.4. 1  Track  Functional  Analysis 

During  the  track  phase,  the  requester  has  a  valid  target  position 
and  maintains  contact  throughout  engagement.  The  request  message  is  sent  to 

Secretary  of  Defense,  Commanders  Handbook  for  Joint  Time-Sensitive  Targeting, 
Department  of  Defense,  22  March  2002,  p.  I-2. 
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the  appropriate  authority  for  processing  and  approval.  Target  updates  may  be 
made  through  the  same  process  until  ordnance  is  delivered. 

The  request  for  fires  process  is  subdivided  into  a  series  of 
sequential  events.  First,  a  formatted  request  message  is  created  (either  voice  or 
data  message).  Regardless  of  the  method  used,  the  request  message  is  sent 
and  receipt  is  acknowledged  by  the  receiving  entity.  The  request  may  be  filtered 
through  several  levels  of  command  based  on  organizational  structure,  rules  of 
engagement,  and  commander’s  intent.  Next,  the  target  is  approved  as  valid  for 
prosecution  and  assigned  a  priority.  The  following  items  would  normally  be 
considered  prior  to  validating  the  request:  proximity  to  friendly  forces;  presence 
of  special  operations  or  coalition  forces  without  real-time  blue  force  tracking; 
battle  damage  assessment  from  previous  attempts  against  target;  collateral 
damage  estimates;  military  law  or  Intel  pre-set  no-fire  zones;  and  request 
duplication.  The  validated  target  is  then  forwarded  to  a  target-provider  pairing 
authority  and/or  an  automated  algorithm  within  the  target  system  function. 

2.3.3.2  Target  Functional  Analysis 

The  targeting  phase  begins  with  a  validated  target.  To  generate  a 
provider  tasking  the  system  will  assess  desired  effects,  engagement  options, 
assets  available,  location  of  available  assets,  and  target  environment.  The 
algorithms  required  to  generate  the  pairings  can  be  automated  or  manually 
processed  within  a  system,  organization,  or  staff. 

The  request  processing  function  and  the  assignment  of  a  fire 
support  provider  are  intertwined,  but  the  methodology  options  to  determine  the 
pairings  of  the  requests  with  the  providers  is  a  unique  function  with  numerous 
options.  Regardless  of  the  specific  methodology  involved,  a  method  or  process 
is  needed  to  perform  the  function  of  matching  or  pairing  a  request  with  a 
weapon  system. 

The  system  should  allow  providers  responding  to  a  validated  target 
to  be  re-tasked,  if  required.  If  a  higher  priority  target  “pops  up”,  assets  on  the 
ATO  with  lower  priority  targets  should  be  considered  as  available  providers. 
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Depending  on  operational  tempo,  it  may  not  be  advantageous  to  change  the 
ATO.  However  lessons  learned  from  Desert  Storm  indicate  that  “flexibility  of  the 
ATO  must  be  improved  to  account  for  changes,  shifting  priorities  and  real  time 
target  requirements  as  the  campaign  progresses.”"^^ 

When  the  provider-target  pairing  (and  deconfliction  functional 
process,  if  required)  is  completed,  the  authority  to  task  the  asset  is  obtained  and 
tasking  message  is  generated. 

2.3.3.3  Engage  Functional  Analysis 

The  engagement  phase  begins  when  the  tasking  order  is 
transmitted  to  the  designated  fires  provider  and  receipt  is  acknowledged.  This 
tasking  can  be  voice  or  a  data  message  specific  to  the  provider  platform 
receiving  the  order  (i.e.,  MFCS,  AFATDS,  ATWCS,  Link  16,  etc.).  The  provider 
should  have  the  capability  to  return  the  task  to  the  tasking  authority  (reclama  or 
cantco  [can  not  comply]  for  authorized  reasons  such  as  low  fuel  state  or  lack  of 
weapons).  Additionally,  the  requesting  unit  should  be  informed  of  the  tasking 
and,  at  a  minimum,  be  provided  with  a  reply  delineating  who  is  providing  the 
support  and  when  it  should  be  expected. 

Concurrent  with  the  provider  tasking,  an  asset  to  provide  battle 
damage  assessment  (BDA)  should  be  identified.  For  the  targets  considered,  time 
sensitive  in  direct  contact,  the  requester  is  assumed  to  be  capable  of  providing 
this  BDA. 

For  some  targets,  it  may  be  required  to  establish  direct 
communications  from  the  provider  to  the  requester.  This  may  include  “Danger 
Close”  situations  with  artillery  or  naval  guns,  and  most  close  air  support  missions 
rely  on  voice  communications  to  prevent  fratricide. 

The  proposed  system  does  not  consider  the  actual  engagement. 
Once  the  provider  is  tasked  and  the  requester  is  informed.  The  engagement 
becomes  a  matter  of  the  tactical  operation  of  the  weapon  platform.  BDA  is 
presumed  to  feed  into  the  common  operating  picture  so  that  destroyed  targets 

Department  of  the  Navy,  “U.S.  Navy  in  Desert  Storm  and  Desert  Shield,” 
rhttp://www.historv. navv.mil/wars/dstorm/ds6.htm1.  Sept  06. 
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are  not  re-attacked.  Similarly,  requests  for  re-engagement  are  treated  as  a  new 
request  with  an  updated  priority  based  on  current  operational  situation. 


2.3.4  Functional  Hierarchy 

The  functions  identified  in  the  F2T2EA  functional  analysis  were  distilled 
and  arranged  into  a  hierarchy  of  functions.  The  advantage  of  this  construct  is 
that  it  allows  analysis  of  functions  based  on  functional  groupings  instead  of  a 
chronological  sequence. 

The  Track  phase  of  the  F2T2EA  process  is  simply  the  transmission  of  the 
fire  support  request  data.  The  next  phase  of  the  system  can  be  sub-divided  into 
four  distinct  functions:  process  request,  match  user  to  provider,  task  the  provider, 
and  send  tasking  feedback  to  the  requester.  Once  tasked,  the  provider 
acknowledges  the  receipt  of  the  tasking  by  accepting  or  declining  the  tasking. 
This  reply  from  the  provider  defines  the  end  state  boundary  of  this  system 
design.  All  of  these  functions  are  enabled  by  the  communication  of  data,  intent, 
and  authority  between  the  functions.  The  hierarchy  of  functions  for  the  proposed 
system  is  shown  in  Figure  21. 


Figure  21:  Functional  Hierarchy 
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2.4  NEEDS  ANALYSIS 


In  accordance  with  the  SEDP,  the  stakeholder’s  needs  and  desires  were 
decomposed,  assessed,  and  compiled  in  an  Analysis  of  Needs. 

2.4.1  Stakeholder  Analysis 

The  primary  purpose  of  stakeholder  analysis  is  to  identify  the  people  or 
agencies  that  are  relevant  to  the  design  problem  and  to  determine  their  needs, 
wants  and  desires  with  respect  to  it.'^^  Due  to  the  size  and  complexity  of  the 
design  problem,  and  the  broad  scope  of  the  JFS  study  area,  determining  the 
stakeholders  was  a  difficult  task.  Thanks  to  the  joint  nature  of  the  Naval 
Postgraduate  School’s  student  body,  the  Project  Team  was  able  to  speak  with 
numerous  groups  of  students  intimately  familiar  with  JFS  procedures  and 
challenges.  The  service-diverse  makeup  of  the  team  also  improved  the  team’s 
ability  to  identify  and  contact  stakeholders  both  on  and  off-campus.  Throughout 
the  stakeholder  analysis  process,  the  stakeholders  were  asked  to  specifically 
identify  and  discuss  their  “needs,  wants,  concerns  and  desires”  for  a  Joint  Fire 
Support  system  of  systems  in  the  year  2020. 

During  the  interview  process  the  team  conducted  several  trips  to  visit 
stakeholders,  arranged  video  teleconferences,  and  made  numerous  telephone 
interviews  with  stakeholders  outside  of  the  local  area.  Group  meetings  were  held 
periodically  with  the  student  and  faculty  stakeholders  identified  at  NPS.  All  of 
these  interviews  were  vital  to  the  process  of  extracting  the  specific  and  overall 
expectations  of  a  proposed  JFS  system. 

Stakeholders  for  a  JFS  system  are  a  diverse  group  with  different 
perspectives  and  priorities.  Identifying  the  perspective  of  the  stakeholder  not 
only  assisted  with  locating  other  stakeholders  with  a  similar  perspective,  but  it 
also  helped  the  team  to  understand  the  motivations  for  the  system  needs  and 
wants  identified  by  the  stakeholder.  The  perspectives  of  the  identified 
stakeholders  run  the  gamut  between  decision  makers  and  end  users  in  the  field. 


B.  S.  Blanchard,  and  W.  J.  Fabrycky,  Systems  Engineering  and  Anaiysis,  4th  ed.,  Pearson 
Prentice  Hall,  2006,  p.  323. 
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The  stakeholders’  perspectives  were  considered  when  the  team  began  fusing  the 
numerous  stakeholder  needs  and  wants  into  a  manageable  and  conclusive  list. 

The  decision  making  stakeholders  have  the  authority  to  make  impacting 
and  final  project  decisions  when  multiple  design  choices  are  available.  For  a 
Joint  Fire  Support  system  that  may  include  tasking  of  joint  military  assets,  one  of 
the  primary  decision  makers  is  Joint  Forces  Command  (JFCOM).  Additionally, 
the  Combatant  Commander  (COCOM)  and  the  acquisition  leadership  of  each 
service  component  were  also  identified.  JFCOM  has  established  the  Joint  Fires 
Integration  and  Interoperability  Team  (JFIIT)  at  Eglin  AFB,  Florida  to  “act  as  the 
lead  agent  for  USJFCOM  to  investigate,  assess,  and  improve  the  operational 
effectiveness  of  joint  fires. The  team  contacted  JFIIT  and  conducted  several 
telephone  interviews.  Additionally,  the  team  traveled  to  JFIIT  in 
June  2006  and  met  with  them  again  at  the  National  Training  Center,  Fort  Irwin, 
California  in  October  2006.  JFIIT’s  insights  were  vital  to  the  identification  of 
JFS  needs. 

The  organizational  leadership  entities  of  any  proposed  JFS  system  would 
certainly  have  a  significant  input  into  the  decision  maker  category.  This  includes 
leadership  utilizing  the  system  to  lead,  direct,  and  protect  their  forces.  At  higher 
command  levels  further  from  the  battlefield,  the  military  leader’s  needs  and  wants 
are  not  the  same  as  the  needs  and  wants  of  the  battlefield  commander.  For  this 
reason,  the  team  consulted  with  mid-level  military  leaders  from  all  of  the  combat 
services.  Through  trips  to  Fort  Sill,  Oklahoma,  Fort  Irwin,  and  Nellis  AFB, 
Nevada  the  team  was  able  to  gather  the  wants  and  needs  of  a  wide  range  of 
military  leaders  involved  in  JFS.  At  Fort  Sill,  the  team  interviewed  the  USMC 
detachment  responsible  for  training  Marines  to  operate  AFATDS  and  its 
associated  systems  and  later  the  AFATDS  program  manager  for  software 
development.  At  Fort  Irwin,  the  team  interviewed  National  Training  Center 
exercise  participants  in  the  field  during  maneuvers  and  assisted  JFIIT  personnel 
with  data  collection  efforts  during  the  exercise.  At  Nellis  Air  Force  Base,  the 


Department  of  Defense,  “Joint  Fires  Integration  and  Interoperability  Team  (JFIIT),” 
[http://www.jfcom.mil/about/comJfiit.htm  ],  May  06. 
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team  consulted  with  the  cadre  of  Air  Warrior,  the  organization  responsible  for  the 
CAS  component  of  the  National  Training  Center  exercises.  Additionally,  the 
team  met  with  the  Joint  Test  &  Evaluation  agency  for  Joint  Fires  Coordination 
Measures  and  the  Joint  Air  to  Ground  Operations  Group. 

The  team  had  the  unique  opportunity  to  attend  the  National  Fire  Control 
Symposium  in  Tucson,  Arizona  to  discuss  JFS  with  both  defense  contractors  and 
academia.  The  involved  agencies  that  presented  concepts  for  future  JFS 
included  Raytheon,  NAVSEA,  MIT  Lincoln  Labs,  and  Lockheed,  among  others. 

The  most  obvious  group  of  stakeholders  for  a  JFS  system  is  the  engaged 
troop  requesting  the  JFS.  Discussions  with  numerous  combat  veterans  on  NFS, 
at  Fort  Sill,  and  at  Fort  Irwin  provided  the  team  with  a  very  solid  understanding  of 
the  desires  for  this  group  of  stakeholders.  Additional  information  on  the  methods 
used  to  identify  and  specific  comments  made  by  the  stakeholder  can  be  found  in 
Appendix  D. 

After  fusing  the  input  from  all  of  the  stakeholders,  the  following  list  of 
“needs,  wants,  concerns  and  desires”  that  defines  the  characteristics  of  any 
proposed  JFS  system.  The  list  below  is  arranged  in  relative  order  of  importance: 

•  Efficient  Turn-Around  Time  On  Fire  Support  Requests 

•  Reliable  System 

•  Very  High  Level  Of  Availability 

•  Flexible  Communication  Methods 

•  Ability  To  Manually  Override  Any  Automation 

•  Easy  To  Maintain  And  Setup 

•  Simple  Training 

•  Scalable  System 

•  Interoperability  With  Current  Platforms 

•  Share  A  Common  Awareness 

•  Efficient  And  Accurate  Decision  Support 

•  Reliable  Archiving  Of  Historical  Message  &  Tasking  Data 

•  Uncomplicated,  Straightforward  System  Operation 
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2.4.2  Effective  Need 


The  Needs  Analysis  process  allows  for  a  summation  of  the  stakeholder 
defined  needs  into  a  refined  and  summarized  need  statement.  Based  on  the 
current  state  of  JFS,  the  anticipated  future  capabilities  for  JFS,  and  the  needs 
and  desires  of  the  stakeholders  involved,  the  effective  need  that  will  drive  the 
proposed  system  design  and  define  the  functional,  physical,  and  operational 
architectures  of  the  solution  is  to:  “Define  an  operationally  feasible  Joint  Fires 
request,  coordination,  and  tasking  architecture  that  enables  rapid  battlefield 
effects  for  the  Commander.”  Any  system  design  alternatives  will  be  measured  by 
their  ability  to  satisfy  this  effective  need  statement. 

2.4.3  Hierarchy  of  Objectives 

The  individual  needs  identified  through  stakeholder  analysis  and  review  of 
source  documents  were  consolidated  and  organized  into  the  Objectives 
Hierarchy  shown  in  Figure  22.  System  objectives  are  composed  of  functions  and 
attributes.  This  Objectives  Hierarchy  allowed  the  Project  Team  to  develop 
relevant  metrics  and  measures  of  effectiveness  used  to  evaluate  the 
performance  of  design  alternatives.  A  detailed  discussion  of  the  system 
attributes  and  metrics  follows  in  Sections  2.5  and  2.6. 
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Figure  22:  Objectives  Hierarchy 


2.5  NECESSARY  SYSTEM  OBJECTIVES 

The  functions  and  attributes  that  the  proposed  system  must  possess  can 
be  traced  to  three  sources:  the  intended  environment  of  the  system,  essential 
stakeholder  needs,  and  analysis  of  the  source  documents  requesting  the  system. 
The  Project  Team  sorted  and  evaluated  these  objectives  according  to  the 
primary  needs  the  proposed  JFS  system  will  support.  These  objectives  have 
been  segmented  according  to  the  objectives  hierarchy  and  are  described  below. 

The  primary  system  objectives  are:  Request,  Process,  and  Task, 
Coordination,  and  Operational  Feasibilities.  The  sub-objectives  that  make  up 
these  top-level  system  objectives  are  described  Figures  23  and  24.  Any 
proposed  system  must  efficiently  process  a  joint  fires  request  and  then  select  an 
appropriate  provider.  The  processing  of  the  request  must  be  accomplished  in 
less  time  than  the  current  JFS  system  (Figure  23). 
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Figure  23:  Request,  Process,  and  Task  Objectives  of  the  System 

The  proposed  system  must  provide  efficient  procedures  for  tasking  of 
effects-based  requests  and  must  be  able  to  pass  those  tasking  orders  to  a 
variety  of  weapon  systems  in  a  format  that  is  useable.  A  variety  of  methods  and 
procedures  exist  to  request  fire  support  depending  on  the  service,  type  of 
delivery  platform,  and  area  of  operations.  Any  proposed  JFS  system  must 
simplify  the  request  process  and  standardize  the  information  required  to  engage 
the  target. 

The  prioritization,  pairing,  and  deconfliction  algorithms  used  in  this 
process  must  be  flexible  in  order  to  support  a  variety  of  operational  environments 
and  changing  ROE  in  support  of  the  commander’s  intent.  A  single,  fixed 
algorithm  for  pairing,  prioritization  or  deconfliction  is  insufficient  to  support  the 
broad  spectrum  of  commander’s  intent.  Dynamic  algorithms,  or  a  selection  of 
algorithms  that  provide  varying  degrees  of  control,  collateral  damage 
considerations,  and  asset  risk  are  appropriate  and  required  to  support  a  variety 
of  operations  and  enable  the  process  to  be  scaled  and  tailored  to  the  current 
environment.  The  system  must  also  possess  key  attributes  related  to  the 
coordination  of  requests  and  tasking  orders  (Figure  24). 
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Figure  24:  Coordination  Objectives  of  the  System 

The  proposed  system  must  integrate  the  individual  service  capabilities  into 
a  joint  fires  effort,  standardize  training,  tactics  and  procedures,  and  consolidate 
and  fuse  a  variety  of  C2  information.  It  should  provide  greater  horizontal  and 
vertical  integration.  The  final  top-level  system  objective  is  operational  feasibility 
(Figure  25). 


Figure  25:  Operational  Feasibility  Objectives  of  the  System 

Feasibility  encompasses  the  foundations  required  to  actually  produce  and 
field  the  family  of  systems  that  enable  joint  fire  support.  In  short,  the  system 
must  work  in  the  way  that  it  was  intended  to  work.  Operational  feasibility  must  be 
assessed  in  the  fielded  environment  and  it  must  meet  or  exceed  accepted  levels 
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of  performance.  A  JFS  system,  as  the  basis  of  its  design,  should  be 
interoperable,  usable,  reliable,  available,  and  sustainable  over  the  duration  of  an 
operation 
or  mission. 

In  order  to  meet  the  need  for  interoperability,  the  system  under 
consideration  must  be  able  to  accept  requests  from  all  four  service  components, 
SOCOM,  and  potential  allied  or  coalition  forces  and  pass  data  and  tasking  orders 
along  to  a  similar  variety  of  providers.  Individual  fielded  systems,  including 
request  input  devices,  radios,  data  fusion  tools,  and  C2  systems  should  meet 
specified  usability,  reliability,  maintainability,  and  availability  requirements 
developed  in  the  detailed  design. 

The  usability  of  the  system  is  an  attribute  that  assesses  or  determines  the 
ease-of-use  of  interfaces.  It  should  include  system  efficiency,  errors,  and 
satisfaction  of  the  user.  Reliability  of  the  system  refers  to  the  ability  of  the 
system  to  perform  and  maintain  its  designed  function  in  routine,  hostile,  or 
unexpected  situations  or  circumstances.  The  standard  for  maintainability  should 
be  that  the  system  will  be  maintained  in  or  restored  to  the  specified  working 
condition  within  a  set  standard  of  time,  provided  the  appropriate  maintenance  is 
performed  in  accordance  with  the  designed  maintenance  procedures  and 
available  resources.  Availability  standards  refers  to  the  degree  to  which  a 
system  or  sub-system  is  available  and  operable.  In  simple  terms,  it  is  the  time  a 
system  is  available  to  perform  the  function  it  was  designed  to  perform.  A  true 
assessment  of  Operational  feasibility  can  only  be  done  on  a  more  detailed, 
physical  SoS  design.  Reliability  of  the  conceptual  systems  is  qualitatively 
assessed  in  chapter  6,  Risk  and  Reliability 

2.6  SYSTEM  METRICS 

The  necessary  system  attributes  and  essential  functions  defined  in  the 
previous  sections  were  assessed  and  divided  into  those  objectives  that  could  be 
directly  measured  (quantifiable  metrics)  and  those  that  could  only  be  subjectively 
assessed  or  validated  (qualitative  metrics).  The  Objectives  Hierarchy  developed 
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in  Section  2.4.3  was  studied  to  determine  how  to  assess  satisfaction  of  those 
needs.  The  results  of  that  analysis  were  the  metrics  that  should  be  evaluated. 
Several  quantifiable  metrics  were  identified  for  evaluation  using  modeling  and/or 
simulation.  Those  metrics  are: 

1 .  Processing  Time  (for  a  Request  to  be  Serviced) 

2.  Pairing  Effects  Ratio 

3.  Number  of  Systems  Involved  (in  the  Request-to-Tasking  Process) 

4.  Number  of  Decision  Points  (involved  in  the  Request-to-Tasking 
Process) 

5.  Number  of  Steps  Involved  in  the  Process 

6.  Number  of  Process  Gaps  (in  the  Request-to-Tasking  Process) 

7.  Blue  Force  casualties. 

These  metrics  can  each  be  traced  to  an  identified  need  in  the 
Objectives  Hierarchy,  as  seen  in  Figure  26. 
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EFFECTIVE  NEED: 

Define  an  Operationally  Feasible  Joint  Fires  Request,  Coordination,  and  Tasking 
Architecture  that  Enables  Rapid  Battlefield  Effects  for  the  Commander. 


Figure  26:  Traceability  of  Quantifiable  Metrics  to  Identified  Needs 


Qualitative  metrics  were  identified  and  assessed  based  on  discussions 
with  stakeholders  and  among  team  members.  Additionally,  qualitative  metrics 
were  influenced  or  defined  by  the  environment  in  which  any  JFS  system  will 
operate  in  and  the  capabilities  of  the  current  JFS  system.  A  summary  listing  of 
potential  metrics  and  functional  breakdown  is  shown  in  Table  4. 


Functions 

System  Objectives 

Metrics 

Coordination 

Standardized  Process 

#  of  Systems  Involved 

#  of  Decision  Points 

Horizontal  &  Vertical 
Integration 

#  of  Steps  in  the  Process 

#  of  Process  Gaps 

Request, 

Process, 

Task 

Reduce  Time  to  Process 

Processing  Time 

Blue  Force  Casualties 

Effects-based  Pairing 

Pairing  Effects  Ratio 

Operationai 

Feasibility 

Availability 

Future  Studies 

Interoperability 

Subjective  Assessment 

Usability 

Future  Studies 

Reliability 

Subjective  Assessment 

Sustainability 

Future  Studies 

Table  4:  Performance  Metrics  of  System  Objectives 


These  metrics  will  be  used  to  compare  proposed  JFS  system  alternatives 
through  modeling,  simulation,  risk  assessments,  and  subjective  evaluation  by 
subject  matter  experts. 
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3.0  PHYSICAL  ARCHITECTURES 


Continuing  with  the  deliberate  SEDP  and  building  on  the  functional 
architecture  developed  in  Chapter  2,  alternative  physical  architectures  were 
developed.  By  design,  a  physical  architecture  “should  provide  resources  for 
every  function  identified  in  the  functional  architecture.”'^'^  To  do  this,  the  physical 
alternative  must  be  built  in  a  way  that  meets  the  identified  needs  and  fulfills  the 
identified  functions.  The  physical  architectures  generated  by  the  Project  Team 
accomplished  this  because  they  were  conceived  in  the  context  of  the  DOTMLPF 
construct  and  address  the  uncertainties  of  several  scenario  concepts.  This 
section  will  first  describe  the  proposed  system  alternatives.  Then,  scenarios  will 
be  used  as  the  backdrop  for  evaluation  of  those  alternatives  presented.  The 
anticipated  environment  and  the  associated  threats  to  a  JFS  system  are  also 
elaborated  as  part  of  the  development  of  the  physical  architectures. 

3.1  GENERATION  OF  ALTERNATIVES 

The  team  began  developing  alternatives  for  the  system  with  an 
understanding  of  the  operational  environment  and  the  stakeholder  needs.  Using 
concepts  developed  from  the  stakeholder  discussions  or  linked  to  the  user- 
defined  needs  and  wants,  the  team  developed  numerous  distinct  alternative 
concepts  for  the  proposed  system.  The  methodology  and  concepts  developed 
during  the  team’s  generation  of  alternative  architectures  is  discussed  in  more 
detail  in  Appendix  E. 

The  alternative  generation  efforts  produced  five  alternatives  that  were 
assessed  for  feasibility.  Three  distinct  alternatives  were  determined  to  be 
feasible  architectures  in  the  year  2020  and  are  described  in  the  following 
sections.  It  is  important  to  note  that  the  alternatives  all  assume  a  similar  level  of 
peripheral  materiel  acquisition.  For  instance,  current  plans  for  improvement  in 
communication  abilities  for  FOs  include  some  type  of  digital  entry  device  that  can 
send  data  (equivalent  or  follow-on  to  TLDHS).  Additionally,  a  continued 

D.M.  Buede,  The  Engineering  Design  of  Systems,  John  Wiley  &  Sons,  Inc.,  2000,  p.  246. 
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improvement  in  networking  infrastructure  and  the  maturation  of  the  Global 
Information  Grid  (GIG)  is  assumed  for  all  three  alternatives.  The  environment  the 
alternatives  will  exist  in  is  a  factor  in  defining  the  feasibility  of  alternatives  and 
therefore  need  to  be  included  and  addressed. 

3.1.1  Alternative  1 :  Status  Quo  Plus 

The  JFS  process  will  certainly  evolve  between  now  and  2020.  There  are 
already  programs  under  development  that  will  attempt  to  meet  the  needs  of  JFS 
in  2020  and  beyond.  The  Status  Quo  Plus  alternative  is  an  expansion  of  the 
current  “as  is”  system  based  on  the  growth  path  of  existing  programs  of  record. 
This  system  alternative  is  based  on  realistic  improvements  in  both  capabilities 
and  materiel  during  this  timeframe,  but  it  also  retains  many  of  the  current  aspects 
of  fires  support  organizations  and  processes. 

With  respect  to  doctrine,  the  relationships  between  the  services  are  not 
projected  to  fundamentally  change.  The  Marine  Corps  remains  closely  linked  to 
the  Navy,  and  the  Army  to  the  Air  Force.  Each  service  continues  development  of 
its  own  command  and  control  systems,  although  information  sharing  between 
them  is  still  considered  a  benefit  to  interoperability. 

With  respect  to  organization  and  leadership,  technological  advances 
permit  faster  transmission  of  battlefield  data  through  the  same  hierarchical 
structures  used  today.  Where  duplication  of  functionality  exists  between  services 
(e.g.  the  FFCC  (Marines),  BCD  (Army),  and  SACC  (Navy))  a  separate  but  equal 
relationship  remains.  There  is  no  effort  to  consolidate  these  organizations  to  a 
more  comprehensive  joint  capability. 

With  respect  to  materiel,  each  service  continues  its  essentially 
independent  development  efforts.  Systems  which  provide  service  to  fielded 
troops  and  to  delivery  platforms  continue  to  be  thought  of  as  mutually  exclusive 
projects,  stratified  by  service,  development  community,  and  prime  contractor. 
Interoperability  is  thought  of  as  a  “connector”  that  links  otherwise  distinct 
development  efforts.  Service  experimentation  is  characterized  by  configuring 
very  specialized  data  channels  to  complete  a  specific  mission  rather  than  viewing 
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data  transmission  as  a  utility  that  can  be  broadly  applied  for  any  and  all  missions. 
Artillery  requests  can  be  sent  digitally  to  the  requester’s  parent  service  for 
processing  and  pairing.  For  example,  although  the  Army  and  Marines  both  use 
AFATDS,  or  an  AFATDS  derivative/follow-on,  their  databases  and  assets  remain 
functionally  separated  and  requests  do  not  freely  flow  between  these  two 
services.  Continued  development  of  the  Marine  version  of  AFATDS  will  allow 
communication  directly  to  MFCS  through  a  data  converter  resulting  in  some 
degree  of  shared  targeting  database. 

The  pairing  of  requests  and  providers  for  all  other  JFS  requests  is 
primarily  completed  using  a  blended  methodology  based  on  service  component 
of  the  requesting  party  and  a  weapon  system  priority.  The  Air  Force  and  Navy 
are  continuing  the  practice  of  “push  CAS”  to  expedite  servicing  of  tasking  orders. 

The  command  and  control  structure  that  forms  the  organizational 
framework  for  the  sharing,  processing,  and  tasking  of  JFS  in  the  Status  Quo  Plus 
alternative  is  depicted  in  Figure  27. 
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Figure  27:  Status  Quo  Plus  Alternative  Architecture 


The  requester  is  a  forward  element,  such  as  a  FO  or  JTAC,  routing  a 
request  for  fire  support  up  the  chain  of  command.  In  this  architecture,  the  call  for 
fire  request  is  sequentially  sent  to  the  next  organizational  level  and  the  target  is 
either  engaged  with  assets  available  to  that  organization  or  the  request  is 
forwarded  to  the  next  echelon  for  tasking.  If  the  request  is  passed  up  to  the 
Division  or  Corps  Operations  Center,  that  agency  has  the  communications  and 
coordination  ability  to  send  the  request  to  a  joint  functional  organization  for 
support,  such  as  the  ASOC,  DASC,  or  SACC.  The  request  is  then  vetted  within 
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those  organizations  and  a  provider  is  selected  and  tasked  for  support  of 
the  request. 

3.1.2  Alternative  2:  Centralized  Joint  Fire  Support  Network 

This  alternative  will  enable  a  fire  support  request  to  be  sent  into  a  single 
decision  making  organization  and  then  allocated  and  tasked  to  a  provider.  Of 
these  three  alternatives,  this  alternative  most  closely  resembles  the  “911  Call 
Center”  concept  discussed  in  Section  1.5.  The  requesting  unit  would  send  a  JFS 
request  to  one  processing  entity  that  is  either  a  single  organization  at  one 
physical  location  (like  a  JAOC),  or  geographically  dispersed  virtual  organization. 
The  function  of  this  organization  will  be  to  receive,  acknowledge,  process,  pair, 
and  task  the  requests  to  a  provider.  This  organization  maintains  interfaces  with 
and  integrates  portions  of  similar  organizations  such  as  the  SACC,  BCD,  FFCC, 
and  ASOC. 

With  respect  to  doctrine,  the  roles  and  missions  of  the  services  do  not 
fundamentally  change,  but  both  the  Joint  doctrine  and  the  service  doctrine 
change  to  reflect  functional  interoperability  with  respect  to  JFS.  The  Marine 
Corps  remains  closely  linked  to  the  Navy,  and  the  Army  to  the  Air  Force,  but 
broader  implementation  of  JFS  procedures  improves  performance  between  the 
pairs.  Changes  in  doctrine  have  very  little  impact  on  the  DoD  acquisition  process 
or  acquisition  planning. 

With  respect  to  organization  and  leadership,  significant  changes  to  the 
request  routing  procedures  increase  the  availability  of  fire  support  providers. 
Headquarters  level  organizations  that  previously  shared  similar  functions  are 
consolidated  and  combined.  The  organization  of  JFS-related  entities  is  not  as 
vertical  as  the  current  system,  especially  prior  to  selection  of  a  provider.  The 
reduction  in  organizational  complexity,  the  shift  from  voice  to  data  messages, 
and  technological  advances  in  communication  systems  result  in  faster 
transmission  of  battlefield  data  through  this  JFS  network.  Overall  processing, 
pairing,  and  decision  making  is  faster  because  the  JFS  resource  owners  are 
organizationally  intertwined  and  combined. 
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With  respect  to  materiel,  the  services  teamed  up  to  develop  and  field  a 
common  data  entry  device  that  allows  transmission  of  requests  back  to  the 
centralized  processing  agency.  This  common  data  entry  device  is  interoperable 
with  artillery  systems  but  not  other  providers.  Interoperability  with  the  other 
providers  is  partially  achieved  through  commonality  of  other  installed  equipment. 
Service  specific  organizations  continue  to  use  separate,  weapon  system-specific 
equipment  to  task  providers. 

Training  requirements  are  simplified  for  most  personnel  in  the  JFS 
network  due  to  system  commonality.  The  reduction  in  specialized  talents  and 
training  reduces  manning  problems  for  requesting  unit  types.  As  a  result  of 
common  training  requirements,  there  is  a  greater  diversity  of  service  and 
functional  experience  mixed  throughout  the  JFS  network.  This  amalgamation  of 
fire  support  expertise  improves  the  common  knowledge  base  of  personnel  within 
the  JFS  entities. 

This  process  and  the  framework  for  the  organization  and  coordination 
within  the  Centralized  Joint  Fire  Support  Network  alternative  is  depicted  in 
Figure  28. 
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Figure  28:  Centralized  Joint  Fire  Support  Network  Architecture 


The  Centralized  JFS  Network  functions  as  follows:  the  requests  for  fire 
would  be  sent  primarily  as  a  digital  data  packet  through  RF  or  IP-based 
communications,  but  units  would  also  have  a  backup  ability  to  send  requests 
using  RF  voice.  A  reply  acknowledging  receipt  of  the  request,  and  the 
notification  of  provider  tasking  and  impending  fire  support,  would  be  sent  back  to 
the  requesting  unit  (via  the  same  method).  The  effects-based  pairing  of  requests 
with  providers  would  be  accomplished  by  the  Joint  Fires  Coordination  Cell. 
Weapon  system  tasking  orders  would  then  be  formatted  to  the  provider’s  needs 
and  sent  to  the  tasked  weapon  system  using  established  or  legacy  tasking 
mechanisms.  Of  course,  as  with  the  existing  system,  if  the  provider  is  unable  to 
perform  the  requested  tasking  then  there  will  be  an  option  for  them  to  “reclama” 
the  tasking  or  reply  with  a  “CANTCO”  (can  not  comply)  message.  The  need  for 
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this  denial  of  tasking  option  will  be  reduced  by  improving  the  accuracy  of  the 
central  processing  facility’s  “available  for  tasking”  list. 

3.1.3  Alternative  3:  Distributed  Joint  Fire  Support  Network 

A  fully  networked  force  that  is  able  to  search  and  share  information 
globally  would  have  great  potential  for  a  JFS  request  and  tasking  system.  This 
alternative  requires  fully  internetworked  capabilities  for  all  JFS  participants,  from 
the  ground  combatant  to  the  providers.  This  alternative  is  conceptually  similar  to 
the  Distributed  Weapons  Capability  work  performed  by  the  John  Hopkins  Applied 
Physics  Laboratory  dealing  with  Theater  Ballistic  Missile  Defense."^^  To  exploit 
that  capability,  requesting  units  send  their  requests  to  a  fire  support  database  via 
the  Global  Information  Grid  (GIG).  A  decision  algorithm  assesses  the  available 
providers  that  are  in  the  database  at  the  time  the  request  was  received, 
processed,  and  posted.  A  common  algorithm  is  used  to  determine  the  best 
tasking  with  regard  to  weapon  effects,  deconfliction,  and  availability  and  a 
preferred  shooter  is  selected.  Based  on  the  request  origin  and  the  proposed 
provider,  a  dynamic  chain  of  command  is  constructed.  The  pairing  is 
immediately  approved  by  the  responsible  commander  and  the  fire  support 
provider  answers  the  tasking.  In  cases  where  a  legacy  weapon  system  is 
technologically  incapable  of  connecting  to  the  JFS  database  via  the  GIG,  the 
functional  agency  responsible  will  perform  surrogate  duties  related  to  the 
evaluation  and  algorithm  calculation  and  will  task  the  weapon  as  appropriate. 

With  respect  to  doctrine,  in  this  alternative  both  the  Joint  doctrine  and 
each  service’s  doctrine  will  change  significantly  to  reflect  extensive 
interoperability,  especially  with  respect  to  JFS.  Improvements  in  Joint  doctrine 
and  tactics  will  effectively  eliminate  the  service  pairings  of  the  past — each 
component  is  confident  and  comfortable  working  with  the  other.  Acquisition 
planning  and  procedures  evolve  to  reflect  the  shift  in  doctrine. 

With  respect  to  organization  and  leadership,  the  fluid  process  of 
distributed  JFS  spawns  organizations  similarly  flexible  in  this  alternative 

Shafer,  Phillippi,  Moskowitz,  and  Allen,  “Distributed  Weapons  Coordination  Conceptual 
Framework,”  Johns  Hopkins  APL  Technical  Digest,  Vol.  23,  Nos.  2  and  3,  2002,  pp.  223-236. 
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architecture.  Dynamic  chains  of  command  link  requesters  with  fire  support 
providers  and  permit  oversight  based  on  weapon  functionality,  not  service.  All 
JFS  organizations  are  networked  and  collaborative.  The  reduction  in  tasking 
complexity,  the  shift  from  voice  to  data  messages,  and  technological  advances  in 
communication  systems  result  in  faster  transmission  of  battlefield  data  through 
this  JFS  network.  Legacy  organizations  like  the  SACC,  BCD,  and  FFCC  remain 
only  as  a  back-up  capability  and  are  completely  integrated. 

With  respect  to  the  materiel  envisioned  for  this  alternative,  the  services 
widely  field  a  common  data  entry  device  that  effectively  extends  advanced 
communications  capabilities  to  the  “edge”  of  the  battlefield.  Not  only  does  it  send 
requests  for  JFS,  but  it  can  also  relay  information  directly  to  and  from  the 
responding  fire  support  providers.  Legacy  weapon  systems  continue  to  rely  on 
voice  coordination  for  engagement.  Service-specific  legacy  C2  systems  are 
either  consolidated  or  eliminated  and  are  maintained  and  operated  jointly  based 
on  function. 

Training  for  JFS  is  “Joint”  in  nearly  all  respects  in  this  framework. 
Because  of  system  interoperability  and  materiel  commonality,  there  are  limited 
specialization  requirements.  Common  joint  training  is  standard  and  adequate  for 
any  position  within  the  JFS  network.  Tactics  are  improved  through  synergy  in 
JFS  execution  and  planning. 

The  framework  for  the  organization  and  data  processing  of  the  Distributed 
JFS  Network  architecture  as  well  as  the  flow  of  the  request  and  tasking  is 
depicted  in  Figure  29. 
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Figure  29:  Distributed  Joint  Fire  Support  Network  Architecture 


Within  this  alternative,  there  is  a  potential  to  “over-communicate”  and  jam 
or  bog  down  the  network.  This  alternative  assumes  a  fully  networked  decision 
process  at  the  0-5  level  command  and  above.  Ships,  Brigade  Operation 
Centers,  GIG-enabled  aircraft  (controlling  units  or  CAS)  participate  in  the 
decision  process  for  themselves  and  their  assigned  assets.  As  the  technology 
becomes  realized  in  the  field,  the  distributed  decision  process  can  be  pushed 
further  down  to  the  individual  units  eventually  resulting  in  a  fully  networked  force. 
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3.1 .4  Summary  of  Alternative  Architectures 

The  three  alternative  architectures  are  distinctly  different  in  both  structure 
and  approach.  A  comparative  summary  elaborates  the  differences  for  the 
reader.  Table  5  provides  that  summary  of  materiel  and  non-materiel 
characteristics  for  all  three  alternatives. 


Alternative 

Characteristics 

DOCTRINE 

ORGANIZATION  & 
LEADERSHIP 

TACTICS  & 
TRAINING 

MATERIEL 

PERSONNEL 
&  FACILITIES 

Status  Quo 
Plus 

-No  Change  to 
Existing  Service  or 
Joint  Doctrine. 

-No  Consolidation  of 
Existing  JFS-related 
Organizations. 

-Functional  duplication 
of  capability  and  effort 
remains  between 
service-specific  JFS 
Agencies. 

-No  Significant  Changes 
to  JFS  Training 
Procedures. 

-Training  Changes  are 
Limited  to  Service- 
specific  Training  Needed 
to  Meet  Legacy  System 
Improvements. 

-Faster  Comms  due  to 
More  Efficient  Networks 
(Only  between  Upper 
Echelons). 

-Incremental 

Improvements  in  Legacy 
C2  Systems. 

-Data  Input  Devices  are 
Fielded  (Functional  or 
Service-Specific). 

-No  Significant 
Changes  to 

Facility 

Requirements. 

Centralized 

JFSN 

-Joint  and  Service 
Doctrine 

Improvements,  but 
Only  with  Respect  to 
JFS. 

-Doctrinal 

improvements  have 
not  Transferred  to 
Acquisition  Planning. 

-Consolidation  of  HQ- 
level  Organizations  with 
Same  Roles. 

-De-facto  Improvements 
to  Training. 

-Improvements  are  due 
to  Bringing  Different 
People  &  Experiences  to 
Work  Together 
(Air,  Arty,  Naval  Fires 
Experience). 

-Faster  Comms  due  to 
More  Efficient  Networks 
(Only  between  Upper 
Echelons). 

-Incremental 

Improvements  in  Legacy 
C2  Systems. 

-Common  Data  Input 
Device  is  Widely  Fielded. 

-Cross-functional 
Organizations 
Reduce  Facility 
Needs. 

-May  be  Virtual 
Based  on  Comm 
Capabilities 

Distributed 

JFSN 

-Fully  Joint  Doctrine 
with  Corresponding 
Shift  in  Acquisition 
Planning. 

-All  significant  JFS 
organizations  are 
networked  at  all  levels. 

-Dynamic  Chains  of 
Command  based  on 
Pairings. 

-SACC/FFCC/BCD,  etc. 
are  fully  interoperable. 

-Common  Joint  Training 
is  Standard  and 
Adequate. 

-Commonality  Resulting 
from  Elimination  of 
Service/  Functional 
Specific  Equipment 

-  Specialization  NOT  a 
Premium  Skill. 

-Faster  Comms  due  to 
More  Efficient  Networks 
(All  Organizational 

Levels). 

-Comms  at  the  "Edge"  of 
JFS 

-Consolidation  or 
Elimination  of  some 

Legacy  Systems. 

-Common  Data  Input 
Device  is  Widely  Fielded. 

-Virtual,  Distributed 
Organizations 
Change  Facility  & 
Manning  Needs. 

Table  5:  Summary  of  Materiel  and  Non-Materiel  Architectures 

3.2  THREATS  AND  FUTURE  ENVIRONMENT  ASSUMPTIONS 

The  Project  Team  initially  developed  numerous  scenarios  to  highlight 
difficulties  in  requesting  fire  support  with  the  as-is  system.  These  scenarios 
challenged  the  depth  and  breadth  of  the  system  to  illustrate  potential  calls  for  fire 
that  required  support  from  another  service.  The  threats  examined  in  these 
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scenarios  were  similar  to  current  threats.  These  types  were  expected  to  remain 
the  most  likely  opposing  force  faced  by  deployed  units  through  the  2020 
timeframe.  The  proposed  system  should  be  capable  of  supporting  a  combatant 
commander  during  a  major  theater  war,  but  the  more  likely  future  was  expected 
to  be  comprised  of  significantly  lower  intensity  conflicts. 

The  2006  Quadrennial  Defense  Review  states  that  a  “greater  emphasis  on 
the  need  to  address  the  war  on  terror  and  irregular  warfare  activities  including  the 
long  duration  unconventional  warfare,  counterterrorism,  counter  insurgency,  and 
military  support  for  stabilization  and  reconstructions  efforts”  is  required.'^® 

The  expected  threat  included  irregular  forces  operating  in  a  relatively 
permissive  environment.  U.S.  forces  will  likely  be  operating  in  concert  with  the 
host  nation  supporting  counter-insurgency  or  counter-terrorism  operations. 
Popular  support  for  the  insurgent  forces  could  be  high  in  locations.  Proliferation 
of  modern  military  hardware  to  these  forces  has  continued,  resulting  in  irregular 
forces  equipped  comparably  to  today’s  light  infantry.  Conventional  engagements 
are  rare  and  short  lived,  but  engagements  of  squad-sized  and  smaller  elements 
are  frequent. 

3.3  SCENARIOS 

The  baseline  conceptual  scenario  consists  of  a  small  US  ground  force 
element  engaged  by  an  equivalent  or  larger  insurgent  force.  The  engaged  unit 
places  an  effects-based  call-for-fire  with  sufficient  precision  and  timeliness  to 
allow  for  a  variety  of  fire  providers  to  be  considered.  The  basic  scenario  is 
service  independent  because  the  challenges  facing  a  JFS  request  and  tasking 
are  not  different  whether  it  is  a  soldier,  sailor.  Airman,  or  Marine  requesting  fire 
support.  Commander’s  intent  and  Rules  of  Engagement  allow  clearance  of  fires 
and  tasking  orders  to  be  accomplished  by  the  echelon  with  control  over  the 
providing  asset.  For  example,  a  company  has  authority  to  clear  and  task  mortars 
under  its  control,  and  a  brigade  authorizes  and  tasks  artillery  or  helicopters  under 


Secretary  of  Defense,  Quadrennial  Defense  Review,  Department  of  Defense, 
February  2006,  p.  4. 
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its  control.  A  more  detailed  description  of  the  forces  within  each  simulation  or 
model  is  described  in  Chapter  4. 

From  this  generic  scenario  and  expected  threat  environment,  four  specific 
and  detailed  scenarios  were  chosen  to  highlight  the  depth  and  breadth  of  the 
challenges  to  the  current  operations  and  illustrate  the  need  for  improved  fire 
support  processing  and  coordination.  These  scenario  snapshots  describe  a  wide 
spectrum  of  potential  future  operations  in  order  to  provide  analysis  results  that 
are  not  specific  to  a  particular  circumstance.  The  DoD’s  recent  move  to  a 
“capabilities-based”  acquisition  strategy  includes  an  emphasis  on  evaluation  of 
alternatives  in  the  context  of  scenario  uncertainty.  This  is  done  in  order  to 
develop  a  system  that  performs  well  across  a  wide  range  of  possible  situations. 

The  Rear-Area  Ambush  scenario  describes  a  situation  where  an  Army  unit 
can  not  be  supported  by  their  own  service  assets.  The  Riverine  scenario 
describes  a  Navy  unit  that  is  unable  to  get  support  from  naval  assets.  The 
Urban  scenario  describes  a  Marine  unit  whose  own  fire  support  is  unavailable. 
The  High-Value  Target  scenario  describes  a  Special  Operations  team  operating 
outside  the  theater  of  operation  and  the  weapon’s  range  of  associated  tactical 
level  fire  support  assets.  Each  of  these  instantiations  of  the  common  scenario  is 
briefly  discussed  below. 

3.3.1  Rear-Area  Ambush 

The  Rear-Area  Ambush  scenario  was  designed  to  examine  the  challenges 
of  an  Army  unit  operating  outside  of  the  Army’s  established  ground  based  fire 
support  assets.  An  Army  convoy  transiting  a  coastal  road  behind  the  fire  support 
zone  is  ambushed  by  irregular  forces.  The  convoy  is  lightly  armed,  consisting  of 
several  High  Mobility,  Multi-purpose  Wheeled  Vehicle  (HMMWV)  escorting 
several  re-supply  trucks.  An  Expeditionary  Strike  Group,  including  a  Navy 
destroyer,  equipped  with  extended  range  guided  munitions  and  tactical  missiles, 
and  Marine  aviation  strike  aircraft  are  operating  off  the  coast.  These  fixed  and 
rotary  wing  attack  aircraft,  along  with  naval  surface  fires  are  available  to  the 
combatant  commander  as  potential  providers.  The  geography  of  this  scenario  is 
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shown  in  Figure  30. 
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Figure  30:  Army  Call  for  Fire 


3.3.2  Riverine 

This  scenario  was  designed  to  explore  the  challenges  of  the  newly  formed 
Navy  Riverine  Force  operating  without  direct  support  from  Navy-Marine  Corps 
aircraft  based  on  a  Carrier  or  Expeditionary  Strike  Group.  A  four-boat  naval 
riverine  unit  conducting  patrols  along  an  isolated  section  of  the  river  comes  under 
fire  from  hostile  forces  along  the  river.  Assumed  forces  include  the  4  small  boats 
with  .50  caliber  and  smaller  weapons,  while  joint  fires  providers  available  are 
Air  Force  CAS  assets,  Army  artillery,  and  Army  attack  helicopters. 

The  current  concept  of  operations  would  place  these  naval  riverine  forces 
under  the  operational  control  of  the  maritime  component  commander,  and  a 
request  for  fires  support  within  the  context  presented  would  necessitate 
coordination  within  the  joint  forces  commander’s  staff.  Horizontal  communication 
directly  to  the  Army  Battalion  operating  adjacent  to  the  river  would  only  be 
available  if  pre-arranged  as  an  ad-hoc  set  up.  The  geography  of  this  scenario  is 
illustrated  in  Figure  31. 
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Figure  31 :  Navy  Request 

3.3.3  Urban 

This  Urban  scenario  is  designed  to  explore  the  fire  support  options  of  a 
Marine  patrol  in  joint  fires  environment.  The  geography  and  rules  of  engagement 
in  this  scenario  limit  indirect  fires  to  a  counter-battery  nature  only.  This  limits  the 
options  of  fire  support  responders  to  precision  guided  munitions,  preferably 
aircraft  delivered. 

There  is  no  direct  link  from  the  engaged  element  directly  to  the  proposed 
Air  Force  CAS  assets.  The  connection  to  Air  Force  assets  would  require 
coordination  between  the  DASC  and  ASOC  through  the  JOC.  Understandably, 
an  ROE  restrictive  environment  may  demand  higher  authority  for  an  engagement 
order,  but  the  current  system  for  routing  the  request  through  the  various  parallel 
command  structures  places  increased  risk  on  the  operating  forces.  The 
geography  of  this  scenario  is  shown  in  Figure  32. 
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Figure  32:  USMC  Request 


3.3.4  High-Value  Target 

The  High-Value  Target  scenario  was  designed  to  explore  the  depth  of 
command  to  approve  engagement  of  a  High-Value  Target  discovered  outside  the 
established  area  of  operations  of  regular  forces.  Special  Operations  Forces, 
remote  from  the  combat  zone,  locate  a  target  of  national  interest.  Due  to  target 
location,  the  request  for  fire  will  require  approval  from  National  Command 
Authority  and  strategic  assets  will  be  considered  as  possible  firepower  providers. 

Irrespective  of  the  requester  and  provider,  the  proposed  system  must 
allow  communication  to  the  appropriate  level  of  command  for  authorization  and 
tasking  shown  above.  This  highlights  the  depth  of  the  command  structure 
compared  to  the  others  which  examine  joint  information  and  control  across  the 
chain  of  command.  The  notional  geography  of  this  scenario  is  shown  in 
Figure  33. 
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Figure  33:  SOF  Request  for  High  Value  Target 


These  scenarios  represent  instantiations  of  a  common  scenario:  a  call  for 
fire  from  an  engaged  element  that  requires  tasking  of  an  asset  outside  of  his 
service  and  normal  communications  paths. 
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4.0  OPERATIONAL  ARCHITECTURE 


The  functional  and  physical  alternatives  were  used  to  develop  the  system 
operational  architecture.  According  to  Buede,  “the  process  of  developing  the 
operational  architecture.... is  the  only  activity  in  the  design  process  that  contains 
the  material  needed  to  model  the  system’s  performance  and  enable  trade-off 
decisions. 

Because  the  physical  design  of  a  JFS  system  in  the  year  2020  is  a 
necessarily  abstract  system,  the  operational  architecture  is  analyzed  from  a 
similar  abstract  perspective.  Very  little,  if  any,  of  the  physical  systems  or 
software  identified  in  the  physical  architectures  exist  today.  The  operational 
architecture  therefore  focuses  on  the  comparisons  of  doctrinal,  organizational, 
and  tactical  structures  at  a  high  level  of  abstraction. 

4.1  MODELING  ALTERNATIVES 

The  modeling  techniques  selected  are  grouped  into  two  broad  categories: 
qualitative  modeling  and  quantitative  modeling.  Qualitative  modeling  is  used  to 
compare  aspects  of  the  alternatives  that  could  not  be  physically  measured,  such 
as  degrees  of  interoperability  and  usability  of  a  system.  Qualitative  assessments 
of  the  material  system  utility  and  system  design  risks  are  addressed  separately. 
Quantitative  modeling  enabled  more  traditional  analysis  of  performance  between 
architectures  based  on  the  Project  Team’s  identified  metrics. 

The  tools  used  in  the  team’s  modeling  efforts  included  discrete  event 
simulations,  agent-based  simulations,  and  simple  numerical  and  statistical 
simulations.  The  software  programs  used  to  create  these  simulations  and 
analyze  the  results  included  the  Microsoft  EXCEL™,  Imagine  That  Inc. 
EXTEND™,  New  Zealand  Defense  Technology  Agency  MANA,  US  Army  DAFS, 
and  Minitab  Inc.  MINITAB™.  The  metrics  identified  during  earlier  phases  of  the 
study  are  assessed  and  appropriate  methods  of  analyzing  and  measuring  them 


D.M.  Buede,  The  Engineering  Design  of  Systems,  John  Wiley  &  Sons,  Inc.,  2000,  p.  246. 
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are  investigated.  The  models  used  to  measure  these  metrics  are  identified  in 
Table  6. 


Functions 

System  Objectives 

Metrics 

Model 

Coordination 

Standardized  Process 

#  of  Systems  Involved 

Spreadsheet  Model 

#  of  Decision  Points 

Spreadsheet  Model 

Horizontal  &  Vertical 
Integration 

#  of  Steps  in  the  Process 

Spreadsheet  Model 

#  of  Process  Gaps 

Spreadsheet  Model 

Request, 

Process, 

Task 

Reduce  Time  to 
Process 

Processing  Time 

EXTEND  Simulation 

Blue  Force  Casualties 

MAN  A  Simulation 

Effects-based  Pairing 

Pairing  Effects  Ratio 

EXTEND-EXCEL  Sim 

Operational 

Feasibility 

Availability 

Subjective  Assessment 

Future  Studies 

Interoperability 

Subjective  Assessment 

Risk  Assessment 

Usability 

Subjective  Assessment 

Future  Studies 

Reliability 

Subjective  Assessment 

Reliability  Assessment 

Sustainability 

Subjective  Assessment 

Future  Studies 

Table  6:  Models  and  Simulations  Used  (by  Metric) 


4.2  QUALITATIVE  SPREADSHEET  MODELING  OF  JFS  PROCESS 
ALTERNATIVES 

Each  of  the  proposed  alternatives  requires  different  message  processing 
and  coordination  steps.  A  descriptive  model  of  each  proposed  JFS  alternative 
was  constructed  and  the  processes,  organizations  and  systems  involved  with  a 
variety  of  joint  fire  support  requests  (based  on  the  scenarios  in  Section  3.3)  were 
studied.  This  analysis  produced  three  conclusions: 

1 )  CJSFN  had  the  fewest  number  of  decision  steps  and  process  delays 

2)  DJSFN  &  CJFSN  had  the  fewest  systems  and  process  gaps 

3)  The  Status  Quo  Plus  had  the  most  steps  for  all  categories 
The  models  used  to  arrive  at  these  conclusions  are  described  below. 

4.2.1  Spreadsheet  Model  Description 

This  static  model  traces  the  process  delays  and  value  added  steps  in  the 
fire  support  request  process.  This  includes  steps  when  the  data  is  reformatted 
and  transferred  from  system  to  system  (i.e.,  an  AFATDS  data  file  is  manually 
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reformatted  into  a  voice  radio  transmission  to  an  airborne  platform)  and  the 
updates  or  changes  to  the  common  operating  picture  command  and  control  data 
that  are  necessary  for  decision  making. 

The  metrics  specifically  assessed  in  this  model  include:  the  number  of 
different  systems/equipment  items  needed,  the  number  of  decision  points 
(actions  taken),  the  number  of  steps  needed  to  complete  a  joint  fire  support 
request,  and  the  “process  gaps”  between  those  systems.  A  process  gap  is 
defined  as  a  process  step  where  data  has  to  be  transformed  from  one  type  to 
another  (i.e.  a  data  file  is  manually  converted  to  voice  or  different  data  format)  or 
where  a  new  system  input  must  be  compared  to  the  previously  developed  target 
information.  For  example,  an  Army  call  for  fire  to  Marine  Corps  artillery  is 
coordinated  using  the  CPOF  C2  system.  When  this  request  is  sent  to  the  Marine 
Corps,  the  target  information  may  be  re-validated  through  C2PC,  GCCS-M, 
and/or  TBMCS  before  organization  approval  may  be  obtained. 

In  order  to  explore  the  depth  and  breadth  of  the  expected  JFS 
environment,  this  analysis  was  performed  for  each  of  the  four  scenarios  concepts 
and  the  results  were  averaged  for  comparison. 

4.2.2  Spreadsheet  Model  Assumptions 

A  number  of  assumptions  were  made  in  this  system  analysis.  First,  the 
communication  backbone  was  assumed  to  exist.  This  backbone  is  currently 
being  referred  to  as  the  Global  Information  Grid  (GIG).  Counting  the  system 
permutations  possible  within  the  GIG  is  well  beyond  the  scope  of  the  project. 
Second,  for  both  the  CJFSN  and  DJFSN  alternatives  several  fully  interoperable 
(or  common)  systems  are  available.  The  system  functions  for  AFATDS,  MFCS, 
and  any  other  future  battlefield  aid  are  assumed  to  be  fully  interoperable  (or 
common).  Facilitating  this  and  enhancing  interoperability  with  other  radio 
systems,  all  fielded  tactical  radio  systems  conform  to  the  roadmap  of  the  JTRS 
program.  Airborne  radios  are  all  assumed  to  be  interoperable  with  a  JTIDS  or  a 
JTIDS-like  standard.  This  infers  complete  interoperability  with  JTRS.  Finally,  in 
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accordance  with  the  JBMC2  Roadmap  recommendations,  all  C2  systems  will  be 
interoperable  (or  common)  in  this  model. 

4.2.3  Spreadsheet  Model  Results 

Tables  which  fully  outline  the  modeling  results  for  each  scenario  may  be 
found  in  Appendix  I.  A  summary  table  of  the  model  metrics  is  shown  in  Table  7. 


Status  Quo  + 

Centralized  JFSN 

Distributed  JFSN 

2  Average  #  of  Steps 

10.2 

6.8 

7.8 

<  Average  #  of  Process  Gaps 

0^  Average  #  of  Process  Delays 

5.0 

1.4 

1.2 

6.8 

4.8 

5.7 

^  Average  #  of  Systems  Needed 

9.0 

3.0 

3.0 

>-  Average  #  of  Steps 

10.0 

8.2 

8.8 

>  Average  #  of  Process  Gaps 

4.2 

1.7 

1.7 

Q  Average  #  of  Process  Delays 

8.0 

6.6 

7.2 

O  Average  #  of  Systems  Needed 

9.8 

3.0 

3.0 

^  Average  #  of  Steps 

8.6 

7.2 

8.2 

2  Average  #  of  Process  Gaps 

4.8 

2.2 

2.0 

>  Average  #  of  Process  Delays 

7.2 

4.5 

6.8 

^  Average  #  of  Systems  Needed 

9.6 

3.8 

4.0 

^  Average  #  of  Steps 

19.0 

14.5 

15.0 

^  Average  #  of  Process  Gaps 

8.5 

3.0 

3.0 

>  Average  #  of  Process  Delays 

16.0 

11.5 

12.0 

^  Average  #  of  Systems  Needed 

13.5 

5.0 

5.0 

Table  7:  Summary  Table  of  Model  Metrics  for  All  Alternatives. 


Lower  values  generally  equate  to  a  more  preferred  process  (i.e.,  the  fewer 
the  processing  delays  the  better  the  system  will  perform)  and  these  lower  values 
are  individually  highlighted  in  the  table  rows. 

The  average  number  of  steps  and  the  number  of  potential  process  delays 
in  the  alternatives  are  highly  correlated  and  may  be  used  interchangeably  to 
describe  the  general  behavior  of  the  other.  The  organizational  designs  of  the 
CJFSN  and  DJFSN  alternatives  have  fewer  steps  than  Status  Quo  Plus. 
Interestingly,  DJFSN,  which  is  the  most  automated  alternative,  has  about  one 
more  step  on  average  than  CJFSN.  This  is  due  to  the  addition  of  the  decision 
algorithm  while  maintaining  a  coordination  step  with  the  organization  formerly 
responsible  for  the  decision. 

The  average  number  of  systems  used  is  most  highly  sensitive  to  the 
number  of  C2  systems  of  record  in  use.  The  Status  Quo  Plus  alternative  retains 
the  portfolio  of  C2  systems  in  use  today  whereas  the  other  alternatives  assume 
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only  one  fully  interoperable  C2  system  for  all  the  services.  For  CJFSN  and 
DJFSN,  the  average  number  of  systems  used  approached  the  bottom  limit  of  the 
model;  one  system  for  the  data  transfer,  one  system  for  the  weapon  control 
system,  and  one  C2  system  of  record. 

Finally,  the  average  number  of  process  gaps  declined  in  step  with  the 
decrease  in  number  of  systems  used.  Based  on  our  counting  methods  (see 
Appendix  I),  the  ratio  of  process  gaps  to  number  of  systems  needed  stayed 
relatively  constant  (2  process  gaps:  3  involved  systems).  The  averages  of  all  of 
these  metrics  across  all  four  scenarios  are  summarized  in  Table  8. 


For  All  Scenarios: 

Status  Quo  Plus 

Centralized  JFS 

Network 

Distributed  JFS 

Network 

Average  #  of  Steps 

12.0 

9.2 

10.0 

Average  #  of  Process  Gaps 

5.6 

2.1 

2.0 

Average  #  of  Process  Delays 

9.5 

6.9 

7.9 

Average  #  of  Systems  Needed 

10.5 

3.7 

3.8 

Table  8:  Relative  System  Preferences. 


This  model  reveals  a  preference  of  either  CJFSN  or  DJFSN  over  Status 
Quo  Plus.  CJFSN  may  have  slightly  better  performance  than  DJFSN. 

4.3  QUANTITATIVE  MODELING 

The  nature  of  the  proposed  system  and  the  timeframe  that  it  will  exist 
within  posed  challenges  to  the  overall  modeling  approach.  The  physical 
components  that  are  proposed  to  make  up  the  physical  alternatives  do  not  fit  the 
standard  agent-based  modeling  tools  directly  and  networking  analysis  can  rapidly 
become  too  complex  to  complete  with  team  resources.  To  cope  with  this 
challenge,  the  Project  Team  developed  several  smaller  models  from  a  functional 
perspective  (e.g.,  basic  system  transactions). 

The  modeling  and  analysis  efforts  were  separated  into  three  areas: 
analysis  of  organizational  alternatives  (including  overall  communication  system 
disconnects  and  process  delays),  simulation  of  the  pairing  and  decision  making 
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processes,  and  estimation  of  communication  impacts  on  JFS  performance  in  an 
agent-based  simulation. 

4.3.1  Modeling  and  Simulation  of  Organizational  Alternatives 

A  discrete  event  simulation  was  used  to  analyze  the  proposed  JFS 
network  communication  and  coordination  pathways  in  the  organizational 
alternatives.  This  model  represented  the  flow  of  valid  requests  from  engaged 
ground  elements  through  appropriate  command  elements  to  the  provider  and 
was  built  in  EXTEND6™.  This  simulation  was  designed  to  evaluate  the  average 
time  to  process  a  call  for  fire  from  request  to  tasking  for  each  of  the  three 
alternatives. 

The  simulation  generates  requests  for  tasking,  and  routes  them  through  a 
series  of  modeling  blocks  representing  message  processing  entities, 
transmission  delays,  and  decision  makers.  To  gain  insight  into  expected 
performance,  consistent  assumptions  and  components  were  used  to  model  the 
processes  in  each  alternative.  These  models  and  subsequent  analysis  produced 
two  conclusions: 

1)  DJFSN  results  in  the  overall  fastest  time  to  task  fire  support  providers 

2)  The  CJFSN  process  was  quicker  than  the  Status  Quo  Plus  alternative 

The  following  section  focuses  on  a  discussion  of  the  modeling  constructs 

that  represent  the  decision  flow  through  each  alternative  command  and  control 
organization.  Assumed  values  for  system  parameters  that  represent  capabilities 
for  each  alternative  are  presented,  as  well  as  the  other  parameters  that  remained 
constant  for  each  alternative.  A  more  detailed  description  of  how  these  models 
were  built  is  contained  in  Appendix  J. 

4. 3. 1.1  Organizational  Model  Descriptions 

The  Status  Quo  Plus  model,  simplified  in  Figure  34,  represents  a 
baseline  case  for  a  notional  forward  observer  generating  a  call  for  fire  and 
sending  that  request  to  its  commanding  unit,  in  this  case  the  responsible 
company.  This  company-level  unit  evaluates  its  capability  to  engage  the  target 
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with  organic  assets.  The  company  then  engages  the  target  or  forwards  the 
request  to  the  battalion.  The  battalion  then  either  engages  with  assets  under  its 
control,  or  forwards  the  request  to  the  brigade.  Similarly,  the  brigade  then 
engages  or  forwards  the  request  for  the  joint  force  commander  to  provide  air  or 
naval  strike  assets. 


Figure  34:  Status  Quo  Plus  Organization  Model. 


The  Centralized  Joint  Fire  Support  Network  model  is  depicted  in 
Figure  35.  A  call  for  fire  is  generated  by  a  notional  forward  element  as  in  the 
Status  Quo  Plus  model,  but  now  it  is  sent  directly  to  the  Joint  Fires  Cell  (JFC). 
The  JFC  then  processes  the  request,  provides  a  target-provider  pairing, 
deconflicts  the  air  space,  and  authorizes  the  tasking.  The  tasking  order  is  then 
sent  to  the  applicable  fire  support  provider  asset. 


Figure  35:  Centralized  Joint  Fire  Support  Network  Qrganization  Model. 


The  Distributed  Joint  Fire  Support  Network  model  is  depicted  in 
Figure  36.  The  same  call  for  fire  is  generated  by  the  notional  forward  element  but 
it  is  now  submitted  to  a  target  database  via  the  Global  Information  Grid.  This 
automated  provider-based  decision  process  results  in  a  tasking  order  to  the 
“best”  provider  based  on  a  common  decision  algorithm  and  operational  picture 
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held  at  each  command.  This  process  includes  all  0-5  and  higher  commands 
(brigade  and  above  ground  units,  ships,  and  aircraft)  that  control  fire  support 
assets  collectively  evaluate  their  capability  to  engage  the  target.  The 
EXTEND6™  block  diagram  flow  and  parameters  for  each  of  these  alternatives 
are  detailed  in  Appendix  J. 


Figure  36:  Distributed  Joint  Fire  Support  Network  Organization  Model. 

4. 3.1. 2  Organizational  Model  Assumptions 

There  are  several  key  assumptions  in  this  abstract  model.  The  first 
of  these  is  distribution  of  target  types  and  the  weapons  that  are  used  against 
those  target  types.  The  notional  opposing  force  presented  50%  targets  that  were 
Type  0  and  are  able  to  be  directly  engaged  by  company  level  assets.  Target 
Types  1  to  4  required  sequentially  higher  echelon  assets  to  be  tasked  against 
them.  The  probabilities  listed  in  Table  9  were  used  to  generate  requests  with 
these  generic  target  types. 


Generic 
Target  Type 

Probability 

Provider 

Assets 

0 

50% 

Company 

60 

1 

20% 

Battalion 

120 

2 

15% 

Brigade 

96 

3 

7% 

Naval  Fires 

30 

4 

8% 

Close  Air  Support 

2/40  minutes 

Table  9:  Organization  Model  Target  Probability  Distribution  Function  Inputs. 
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Weapon-target  pairing  was  not  specifically  modeled  in  this 
simulation.  The  target  type  abstractly  represents  the  target  characteristics, 
weapon  pairing,  and  deconfliction  of  the  “best”  provider.  The  number  of  provider 
assets  available  was  made  sufficiently  large  enough  that  all  of  the  targets 
presented  could  be  appropriately  prosecuted.  A  summary  of  the  model  input 
data  is  presented  in  Table  9. 

Communications  connectivity  was  assumed  to  be  perfect  and  all  of 
the  targets  presented  were  valid.  All  CFFs  resulted  in  tasking  orders,  and  were 
tasked  to  the  notional  “best”  provider.  Delays  for  processing,  pairing, 
deconfliction,  and  authorization  in  each  alternative  were  applied  from  statistical 
distributions.  These  average  processing  delay  times  were  based  on  the 
judgment  of  the  Project  Team  and  other  Subject  Matter  Experts.  The  average 
engagement  times  were  based  on  a  summary  of  response  time  data  from 
Raytheon"^®  and  RAND"^®  reports,  stakeholder  input,  and  team  observations  of  the 
CFF  request  process  at  the  National  Training  Center  and  AIR  WARRIOR.  Table 
10  summarizes  these  delays  by  alternative. 


U.  S.  Marine  Corps  Marine  Corps  Combat  Development  Command,  “Marine  Corps  Fire 
Mission  Profiling  Through  Experimentation  with  Real  and  Simulated  Systems,”  Raytheon,  2006, 

pp.  1-16. 

Pirnie,  Vick,  Grissom,  Mueller,  Orletsky,  “Beyond  Close  Air  Support,”  RAND,  2005,  pp.  78- 

161. 
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Status  Quo  + 

CJFSN 

DJFSN 

Initial  Call  for  fire  request 

0.5 

0.5 

0.5 

Engagement  Times 

Company  Asset 

3 

3 

3 

Battalion  Asset 

3 

3 

3 

Brigade  Asset 

3 

3 

3 

Close  Air  Support 

10 

10 

10 

Naval  Fires 

10 

10 

10 

Process  and  Tasking  Times 

Company  Asset 

3 

5 

3 

Battalion  Asset 

5 

5 

3 

Brigade  Asset 

5 

5 

3 

Close  Air  Support 

3 

5 

3 

Naval  Fires 

3 

5 

3 

ASOC/DASC/JOC 

5 

Joint  Fires  Cell  decision 

5 

GIG  collaborative  decision 

3 

Table  10:  Summary  of  Simulation  Delays  (Minutes). 


4.3. 1.3  Organizational  Model  Results 

The  model  results  were  output  to  a  spreadsheet  for  analysis  in 
MINITAB™  to  evaluate  the  average  processing  time  for  each  alternative.  A  more 
detailed  description  of  the  analytical  results  is  discussed  in  Appendix  J.  The  null 
hypothesis  for  all  considerations  is  that  there  is  no  processing  time  difference 
caused  by  target  type  or  alternative  system.  Analysis  of  variance  (ANOVA)  was 
conducted  to  reject  or  accept  this  hypothesis  based  on  the  simulation  data. 
Because  the  assumed  statistical  distributions  for  processing  time  were  not 
symmetrical,  the  assumption  of  normally  distributed  data  required  for  ANOVA 
was  suspect  and  a  non-parametric  (Kruskal-Wallis)  analysis  was  conducted  to 
confirm  the  results. 

The  ANOVA  results  rejected  the  null  hypothesis  for  the  full  target 
set.  The  choice  of  Alternative  System  (F  statistic=391,  p=0.0000)  had  a 
statistically  significant  difference  in  response  time,  indicating  at  least  one  system 
is  different  from  the  others.  Non-parametric  results  showed  statistically 
significant  differences  and  ranked  system  performance  as  DJFSN,  CJFSN,  then 
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Status  Quo  Plus  (slowest).  Figure  37  is  a  boxplot  of  the  median  delay  times  for 
each  alternative. 


Boxplot  of  task  delay  vs  S^tem 


SQ+  cjf'sn  djfsn 

System 


Figure  37:  Boxplot  of  Organizational  Delay  Times. 

In  order  to  examine  the  effects  of  the  various  distribution  means 
(the  input  simulation  delays  described  in  Table  10)  on  the  performance  of  each 
system,  a  sensitivity  analysis  was  conducted.  Each  parameter  was  individually 
varied  and  the  overall  mean  tasking  times  were  calculated  for  30  runs.  Of  all 
parameters  altered,  only  the  target  type  distribution  demonstrated  an  interaction 
with  system  response  time.  As  more  targets  requiring  a  tasking  above  the 
company  level  (target  types  1  to  4)  were  generated.  Status  Quo  Plus  system 
performance  degraded  while  DJFSN  and  CJFSN  alternatives  remained  about  the 
same.  Further  detail  of  the  statistical  analysis  and  results  is  contained  in 
Appendix  J. 

Overall,  the  DJFSN  system  required  the  least  amount  of  time  to 
processing  a  call  for  fire,  followed  by  the  CJFSN  then  Status  Quo  Plus. 

4.3.2  Modeling  and  Simulation  of  Pairing  Effectiveness 
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The  effectiveness  of  request-provider  taskings  is  a  key  factor  in  the 
analysis  of  alternative  architectures.  The  applicable  portion  of  the  Effective  Need 
described  a  requirement  to  “maximize  rapid  battlefield  effects  through  efficient 
target-provider  pairings.”  The  pairings  of  targets  and  providers  was  simulated  by 
interlaced  models  that  ran  simultaneously  within  EXTEND6™  and  EXCEL™. 
The  models  that  represented  the  three  alternative  architectures  were  distinct 
variations  of  a  common  model.  These  models  were  designed  to  evaluate  the 
differences  in  overall  pairing  effectiveness  achieved  when  considering  either  all 
available  providers  (in  the  CJFSN  and  DJFSN  alternatives)  or  engagement  with 
first  available  asset  (Status  Quo  Plus). 

These  models  and  subsequent  analysis  produced  two  conclusions  and  an 
interesting  observation: 

1 )  An  effects-based  pairing  algorithm  improves  engagement  effectiveness 
over  a  service-based  pairing  methodology. 

2)  Pairing  effectiveness  was  not  sensitive  to  the  differences  in  processing 
delay  times  between  the  CJFSN  and  DJFSN.. 

Observation:  A  pairing  algorithm  capable  of  rapidly  producing  thousands 
of  engagement  recommendations  can  be  built  to  support  future  JFS 
systems. 

The  following  section  describes  the  steps  taken  to  arrive  at  these 
conclusions.  The  model  describes  the  processing  and  decision  actions  as  the 
data  flows  through  each  alternative  weapon-target  pairing  simulation.  Although 
all  of  the  simulation  scenario  structures  describe  an  Army  requester,  the  joint 
relationships  are  what  determine  the  results  and  the  requester  can  just  as  easily 
be  modeled  as  a  different  entity  if  the  names  in  the  rest  of  the  model  are  changed 
appropriately.  A  summary  of  the  analytical  results  of  the  simulation  data  is 
presented  as  a  basis  for  comparison  of  each  alternative. 

4. 3. 2. 1  Pairing  Modei  Descriptions 

The  simulation  models  each  process  and  task  an  identical 
sequence  of  calls  for  fire  that  include  target  type,  target  location  and  desired 
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effects.  Within  each  model,  these  requests  are  routed  through  the  alternative 
pairing  processes  and  a  notional  effectiveness  is  then  applied  to  the  target  (an 
estimated  “probability”  of  achieving  the  “requested  effect”)  based  on  the  resulting 
weapon-target  pairing.  The  notional  effectiveness  applied  to  the  requested  target 
was  then  compared  to  the  best  possible  effectiveness  for  that  target  type, 
location,  and  requested  effects.  A  more  detailed  description  of  the  models, 
assumptions,  and  results  are  contained  in  Appendix  K. 

The  Status  Quo  Plus  model,  represented  by  the  flow  shown  in 
Figure  38,  represents  a  baseline  case  for  a  notional  forward  observer  generating 
a  call  for  fire  that  is  sent  to  the  responsible  company.  Each  level  in  the 
hierarchical  command  structure  (company,  battalion,  and  brigade  assets) 
evaluates  its  capability  to  engage  the  target.  If  they  cannot  service  the  target  due 
to  a  lack  of  available  providers/weapons,  then  they  forward  the  request  up  the 
chain.  Eventually,  the  target  is  engaged  by  the  Army  or  forwarded  to  Air  Force 
CAS.  If  AF  CAS  assets  are  available,  then  the  target  is  engaged  by  AF  CAS, 
otherwise  the  request  is  forwarded  to  the  JOC  for  tasking  of  naval  surface  fires. 
Marine  artillery,  or  Navy-Marine  Corps  CAS  assets. 


Status  Quo  Plus  Pairing 
Model 

Army  (BN-BDE-DIV)  Air  Force  (AOC)  Navy-MC  (JOC) 


Figure  38:  Status  Quo  Plus  Pairing  Model. 
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An  effects-based  pairing  model  representing  the  CJFSN  alternative 
is  depicted  in  Figure  39.  A  call  for  fire  was  generated  and  sent  to  the  Joint  Fires 
Cell.  A  list  of  prioritized  providers  was  generated  by  the  JFC  based  on  target 
type  and  desired  effects  using  a  weapon  effectiveness  table  described  in  the 
assumptions  below.  A  target  location  filter  then  removes  providers  that  are 
infeasible  (out  of  range)  from  the  prioritized  provider  listing.  The  process  then 
sequentially  evaluates  the  availability  of  the  remaining  prioritized  provider  assets 
and  tasks  the  best  one  available,  regardless  of  service. 


Figure  39:  Effects  Based  Pairing  Model. 


The  same  effects-based  pairing  process  was  used  by  the  DJFSN 
model,  but  the  processing  and  coordination  delays  were  different,  representing 
that  model’s  communications  and  coordination  capabilities. 


4. 3. 2. 2  Pairing  Modei  Assumptions 

The  engagement  and  decision  delays  developed  in  the 
Organizational  Alternatives  Models  (Section  4.3.1)  were  used  as  the  input  for  the 
average  time  delays  within  the  pairing  models.  An  additional  engagement  delay 
time  of  3  minutes  was  added  to  these  process  delay  times  to  estimate  the  total 
time  from  arrival  of  the  requests  and  engagement  of  the  target.  The  quantity  and 
effectiveness  of  providers  were  kept  constant  between  all  three  alternative 
models.  The  input  delay  assumptions  are  listed  in  Table  1 1 . 
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Alternatives 

TASKING  TO 
ARMY 

ARTILLERY 

TASKING  TO 

AF  CAS 

TASKING  TO 
MARINE 

ARTILLERY 

TASKING  TO 

NAVAL  FIRES 

TASKING  TO 
NAVY/USMC 

CAS 

ENGAGEMENT 

TIME 

Status  Quo  Plus 

Mean:  14  min 
SD:  4  min 

Mean:  1 7  min 
SD:  5  min 

Mean:  19  min 
SD:  4  min 

Mean:  20  min 
SD:  5  min 

Centralized 

JFS  Network 

Mean:  10  min 
SD:  5  min 

Mean:  10  min 
SD:  5  min 

Mean:  10  min 
SD:  5  min 

Mean:  10  min 
SD:  5  min 

Distributed 

JFS  Network 

Mean:  7  min 
SD:  4  min 

Mean:  7  min 
SD:  4  min 

Mean:  7  min 
SD:  4  min 

Mean:  7  min 
SD:  4  min 

Table  1 1 :  Pairing  Model  Processing  and  Engagement  Delay  Assumptions 

An  identical  target  list  of  1000  targets  was  generated  for  all  of  the 
simulation  models.  This  list  of  target  types,  desired  effects,  locations,  and 
request  arrival  times  was  randomly  determined  beforehand  and  then  fixed  for  all 
of  the  simulation  runs.  The  Target  type  probability  was  evenly  distributed  among 
the  10  options,  and  the  targets  were  generated  in  locations  that  were  evenly 
distributed  across  a  notional  battlefield.  The  assumption  was  made  that  Army 
Artillery,  Marine  Artillery,  and  Naval  Fires  would  have  similarly  sized,  overlapping 
areas  of  fire  support  capability  that  would  permit  them  to  collectively  service  85% 
of  the  target  locations.  The  statistics  for  the  1000  calls  for  fire  are  given  in  Table 
12. 


1000  Requests,  Arrival  Intervals 

Target  Types 

% 

Randomly  Distributed  0-3  min 

Troops  in  the  Open 

10% 

Effects  Type  Requested 

% 

Entrenched  T roops 

11% 

Harass 

5% 

T  rucks 

9% 

Suppress 

15% 

Armored  Personnel  Carriers 

12% 

Neutralize 

48% 

Armor/Tanks 

11% 

Destroy 

33% 

Bunker/Hardened  Structure 

8% 

Targets  within  Range  of: 

% 

Logistics/Assembly  Site 

10% 

Artillery  (Army,  Marine 

86% 

Artillery  Battery 

9% 

Corps)  or  Naval  Fires 

/o 

C2  Site 

10% 

CAS  (AF,  Navy,  USMC) 

100% 

SAMs/SCUDs 

10% 

Table  12:  Pairing  Model  CFF  Inputs 

The  requested  effects  type  categories,  and  the  distribution  of  those  requested 
types,  were  derived  from  stakeholder  input  and  Army  Field  Manual  6-30.  To 
meet  the  request  for  “Harass”  effects,  the  enemy  simply  needs  to  be  concerned 
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about  the  presence  of  enemy  fires.  Suppression  effects  on  a  target  “limits  the 
ability  of  the  enemy  personnel  in  the  target  area  to  perform  their  jobs.”  To 
achieve  the  desire  effect  of  Neutralizing  a  target,  it  must  be  “knocked  out  of 
action  temporarily...  Neutralization  does  not  require  an  extensive  expenditure  of 
ammunition  and  is  the  most  practical  type  of  mission.”®^  Destroy  was  the  most 
severe  requested  effect  and  according  to  the  Army,  “Destruction  puts  a  target  out 
of  action  permanently.”  Interviews  with  Subject  Matter  Experts  (SMEs) 
determined  that  roughly  50%  of  CFFs  request  “Neutralize”  effects,  30%  request 
“Destroy”  effects,  and  the  remainder  request  primarily  “Suppression”  effects.  The 
distribution  of  requested  effects  was  outlined  in  Table  12. 

The  predicted  effectiveness  of  each  weapon  assumed  in  the  model 
is  based  on  requested  effects  and  target  type.  These  weapon-target  pairing 
effectiveness  percentages  are  listed  in  Table  13  and  are  roughly  based  on  Joint 
Munitions  Effectiveness  Manual  (JMEM)  and  stakeholder/SME  estimates. 
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Department  of  the  Army,  Tactics,  Techniques,  and  Procedures  for  Observed  Fire,  Field 
p.  4-9 


Manual  6-30,  July  1991 
Ibid 
Ibid 


108 


REQUESTED 

ARMY 

AF 

USMC 

NAVAL 

NAVY/M  C 

EFFECT 

TARGET  TYPE 

ARTY 

CAS 

ARTY 

FIRES 

CAS 

Troops  in  the  Open 

98% 

25% 

98% 

96% 

25% 

Entrenched  Troops 

60% 

20% 

60% 

50% 

20% 

(0 

(/) 

Trucks 

75% 

40% 

75% 

73% 

40% 

APCs 

60% 

45% 

60% 

53% 

45% 

(0 

Armor 

50% 

45% 

50% 

48% 

50% 

(0 

X 

Bunker/Hardened  Structure 

50% 

20% 

50% 

47% 

20% 

Logistics/Assembly  Site 

98% 

33% 

98% 

96% 

33% 

Artillery  Battery 

25% 

40% 

25% 

33% 

40% 

C2  Site 

94% 

28% 

94% 

93% 

28% 

SAMs/SCUDs 

87% 

7% 

87% 

85% 

7% 

Troops  in  the  Open 

82% 

47% 

35% 

47% 

(0 

(0 

0) 

Entrenched  Troops 

41% 

32% 

41% 

40% 

32% 

Trucks 

62% 

47% 

62% 

60% 

47% 

APCs 

51% 

49% 

51% 

49% 

49% 

Armor 

39% 

48% 

39% 

36% 

48% 

& 

o 

Bunker/Hardened  Structure 

30% 

51% 

30% 

29% 

51% 

3 

Logistics/Assembly  Site 

79% 

36% 

79% 

75% 

36% 

0) 

Artillery  Battery 

19% 

44% 

19% 

26% 

44% 

02  Site 

77% 

36% 

77% 

74% 

36% 

SAMs/SCUDs 

72% 

6% 

72% 

71% 

6% 

Troops  in  the  Open 

73% 

69% 

73% 

71% 

69% 

0) 

N 

Entrenched  Troops 

32% 

41% 

32% 

31% 

41% 

Trucks 

49% 

62% 

49% 

48% 

62% 

APCs 

40% 

54% 

40% 

38% 

54% 

15 

Armor 

26% 

57% 

26% 

25% 

57% 

Bunker/Hardened  Structure 

13% 

63% 

13% 

13% 

63% 

3 

0) 

X 

Logistics/Assembly  Site 

54% 

52% 

54% 

52% 

52% 

Artillery  Battery 

12% 

58% 

12% 

14% 

58% 

C2  Site 

61% 

52% 

61% 

59% 

52% 

SAMs/SCUDs 

59% 

5% 

59% 

63% 

5% 

Troops  in  the  Open 

51% 

63% 

51% 

50% 

63% 

Entrenched  Troops 

23% 

49% 

23% 

22% 

49% 

> 

Trucks 

37% 

77% 

37% 

35% 

77% 

o 

APCs 

21% 

81% 

21% 

20% 

81% 

Armor 

9% 

74% 

9% 

5% 

74% 

(/) 

Bunker/Hardened  Structure 

7% 

72% 

7% 

26% 

72% 

0) 

Q 

Logistics/Assembly  Site 

28% 

58% 

28% 

27% 

58% 

Artillery  Battery 

8% 

72% 

8% 

15% 

72% 

C2  Site 

36% 

63% 

36% 

49% 

63% 

SAMs/SCUDs 

46% 

5% 

46% 

51% 

5% 

Table  13:  Weapon-Target  Pairing  Effectiveness  Model  Input  Matrix 

The  metric  used  to  evaluate  system  performance  was  called  the 
Effects  Ratio.  This  ratio  is  calculated  by  dividing  the  Applied  Effects  (the 
percentage  that  was  actually  applied  by  the  model  as  the  target  was  paired  with 
a  provider)  by  the  maximum  effect  possible  for  that  target-effects  pair  (the  largest 
percentage  in  the  same  row  of  the  table  defined  by  the  target  type  and  desired 
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effects).  For  example,  a  “Troops  in  the  Open”  target  type  with  a  requested  effect 
type  of  “Harass”  that  was  engaged  by  artillery  had  an  effects  ratio  of  1  (.98/.98). 
Engaging  the  same  request  with  CAS  had  an  effects  ratio  of  .26  (.25/.98). 

4.3.2.3  Pairing  Modei  Resuits 

The  model  results  were  output  to  a  spreadsheet  for  analysis  in 
MINITAB™  to  evaluate  the  pairing  effectiveness  for  each  alternative  architecture. 
A  more  detailed  description  of  the  analytical  results  is  discussed  in  Appendix  K. 
The  null  hypothesis  for  all  models  is  that  there  is  no  processing  time  difference 
caused  by  differences  in  pairing  methodology  or  alternative  systems.  Analysis  of 
variance  (ANOVA)  was  conducted  to  reject  or  accept  this  hypothesis  based  on 
the  simulation  data. 

The  ANOVA  results  reject  the  null  hypothesis  (F=13.35,  p=0.000), 
and  indicated  that  at  least  one  alternative  is  different  from  the  others.  Median 
effects  ratio  of  the  Status  Quo  Plus  is  lower  than  both  DJFSN  and  CJFSN.  While 
the  middle  50%  (interquartile)  of  observations  almost  completely  overlap  in  the 
boxplot  of  the  effects  ratio  (Figure  40),  there  is  a  difference  between  the 
alternatives. 
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Boxplot  of  Effect  ratio  vs  Alternative 
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Figure  40:  Statistical  Means  of  Effects  Ratios  by  Alternative 


This  overlap  is  primarily  due  to  the  weapons  effects  table  used. 
Ground  based  fires,  artillery  and  naval  gun  fire,  were  equivalent  and  no 
differentiation  in  the  capability  of  air  assets  were  made.  By  examining  the 
utilization  of  provider  assets  show  in  Figure  41,  the  effect-based  pairing  method 
achieved  a  better  median  Effects  Ratio  by  tasking  more  aircraft;  Navy-Marine 
Corps  CAS  assets  were  available  providers.  The  benefit  of  this  pairing  method  is 
the  potential  for  reducing  the  logistical  requirements  to  support  the  volume  of 
ground  based  artillery  fire  support. 
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Figure  41 :  Provider  Asset  Utilization  by  Pairing  Methodology 

Considering  the  assumed  distributions  for  processing  and 
engagement  times,  along  with  the  weapon  effects  chart,  the  assumption  of 
normally  distributed  data  was  suspect.  A  non-parametric  analysis  (Kruskal- 
Wallis)  was  conducted  to  confirm  the  ANOVA  results.  This  analysis  determined 
that  there  is  no  difference  between  the  CJFSN  and  DJFSN  alternatives,  but  the 
Status  Quo  Plus  alternative  is  statistically  worse  than  the  other  two. 

The  results  from  this  model  indicate  that  an  effects-based  pairing 
algorithm  may  improve  overall  engagement  success.  With  the  given  fixed  target 
set  and  arrival  rate,  the  differences  in  processing  delay  times  between  distributed 
and  centralized  processing  did  not  adversely  affect  the  effectiveness  of  the 
pairing  process. 

An  additional  model  observation  is  that  this  relatively  primitive 
discrete  event  simulation,  with  spreadsheet  lookups,  generated  pairings  of  1000 
targets  in  under  three  minutes.  This  aligns  with  the  processing  delay 
assumptions  used  in  the  organizational  alternatives  model.  It  also  indicates  that 
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a  dedicated  software  package,  using  a  GIG  enabled  database  for  targets  and 
providers,  could  be  developed  with  comparable  results  both  in  effects  and 
processing  time. 

4.3.3  Agent-Based  Performance  Simulation 

The  Project  Team  consulted  with  the  U.S.  Army  Training  and  Doctrine 
Analysis  Command,  Training  and  Analysis  Center-Monterey  (TRAC-Monterey)  to 
assess  appropriate  methods  to  model  JFS  and  was  introduced  to  several 
modeling  and  simulation  tools.  The  two  best  modeling  alternatives  were  the 
Dynamic  Allocation  of  Fires  and  Sensors  (DAFS)  simulation  and  the  Map  Aware 
Non-uniform  Automata  (MANA)  simulation.  The  team  chose  MANA  for  the 
agent-based  modeling  based  on  its  communications  modeling  architecture.  The 
same  scenario  was  tested  among  the  team’s  three  alternatives,  with  the  full 
MANA  output  gathered  for  each  alternative. 

The  simulation  was  designed  to  evaluate  performance  of  the  alternative 
system  in  providing  operational  support  to  a  patrol  in  an  Urban  scenario.  The 
Urban  scenario  was  chosen  as  the  most  difficult  among  the  available  scenarios 
to  demonstrate  each  alternative’s  effectiveness.  Additional  scenarios  were 
assumed  to  yield  similar  results,  and  were  not  modeled  due  to  time  and  resource 
constraints.  Number  of  blue  force  casualties  sustained  was  determined  to 
indicate  relative  effectiveness  of  the  fire  support  system. 

These  models  and  subsequent  analysis  produced  the  following 
conclusion:  Distributed  JFSN  resulted  in  the  fewest  friendly  force  casualties.  The 
models  and  analysis  used  to  arrive  at  this  conclusion  are  described  in  the 
following  sections. 

4.3.3. 1  Agent-Based  Model  Description 

MANA  is  an  agent-based  simulation.  Entities  (agents)  are  given 
sensor  ranges,  weapon  performance  parameters,  and  behavioral  guidelines,  and 
are  then  released  in  the  simulation  to  react  to  conditions  based  on  those 
behaviors.  The  user  is  able  to  shape  outcomes  based  on  an  agent’s  propensity 
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to  engage  or  run  from  the  enemy,  cluster  with  like-minded  agents,  or  seek  cover 
and  concealment.  Macroscopic  interaction  and  outcomes  can  then  be  analyzed 
based  on  the  individual  agent  behaviors. 

The  MANA  model  was  not  intended  to  test  pairing  or  deconfliction 
methodology,  but  rather  to  test  communication  schema  to  determine 
effectiveness  of  Joint  Fire  Support  in  a  scenario.  The  Status  Quo  Plus  MANA 
model  required  a  fires  request  to  route  through  several  separate  steps  (based  on 
analysis  of  command  structure  from  Sections  2.2  and  3.1),  while  the  CJFSN  and 
DJFSN  required  fewer  steps  or  communications.  Aside  from  the  communication 
and  decision  delays,  the  time  for  targets  to  be  accurately  located  and  ordnance 
to  arrive  on  target  are  consistent  throughout  each  alternative.  This  modeling  tool 
does  not  permit  best-provider  pairing.  This  aspect  was  not  measurable  within 
MANA  and  any  fire  support  provider  which  had  ammunition  and  was  within  range 
of  the  target  fired  as  soon  as  it  was  aware  of  a  valid  (hostile)  target. 

An  urban  scenario  was  built  using  downtown  Baghdad  as  the 
notional  geography.  A  company  of  Marines  patrolled  the  city  with  an  Army 
Battalion  to  the  east  with  supporting  artillery  that  was  not  previously  coordinated. 
Marine  requests  for  Army  artillery  support  were  routed,  depending  on  the 
alternative  simulated,  through  either  the  Joint  Operations  Center  (Status  Quo 
Plus),  Joint  Fires  Cell  (CJFSN)  or  directly  to  the  artillery  battery  (DJFSN). 

Each  alternative  was  evaluated  in  the  urban  simulation  with  44  blue 
(friendly)  entities  representing  the  C2,  indirect  fires  providers,  or  front  line  troop 
categories.  The  scenario  layout  is  shown  in  Figure  42.  There  were  two  Joint 
Fire  Support  providers,  in  the  form  of  two  Army  artillery  batteries  of  six  guns 
each,  which  were  able  to  support  Marine  patrols  within  the  city.  Red  forces  were 
held  constant  at  38  entities  and  consisted  of  unconventional  forces  with  enemy 
inferior  weapons,  as  well  as  3  sniper  agents  with  increased  (superior)  detection 
and  weapons  capability.  The  blue  patrol  elements  required,  by  design, 
assistance  outside  their  level  of  capability  (i.e..  Joint  Fire  Support)  in  order  to 
neutralize  the  red  threats  and  allow  the  unit  to  complete  its  mission  (a  complete 
patrol  of  the  area).  A  detailed  description  of  the  MANA  model  along  with 
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information  on  the  exact  location  and  capability  of  each  agent,  and  settings  for 
each  alternative,  is  contained  in  Appendix  L. 


GlueCasiO 


Figure  42:  MANA  Urban  Scenario  Initial  Layout 

4.3.3.2  Agent-Based  Model  Assumptions 

MANA  is  an  implicit  model,  not  an  explicit,  physics-based  model. 
Sensor  ranges,  weapon  performance,  and  probabilities  are  input  by  the  user 
based  on  scenario  assumptions.  These  assumptions  were  based  on  stakeholder 
input  and  the  combined  military  experience  of  the  team.  General  assumptions 
include  friendly  weapon  and  sensor  superiority  (range,  probability  of 
detection/kill)  with  few  exceptions,  enemy  insurgent  behaviors  (propensity  to 
avoid  blue  forces  until  able  to  mass  fire  in  an  ambush-style  attack),  and  95% 
reliable  communications.  Communications  were  assumed  to  be  accurate  with 
the  exception  of  a  sensitivity  analysis  performed  to  analyze  the  effect  of 
communications  problems  on  system  performance. 
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The  Status  Quo  Plus  model  was  built  with  a  serial  call  for  fire 
format.  Requests  are  generated  at  the  lowest  engaged  forward  element  (a 
squad),  and  passed  serially  through  the  chain  of  command  until  it  can  be 
appropriately  serviced.  The  CJFSN  model  sends  all  calls  to  the  Joint  Fires  Cell, 
which  then  notifies  providers  of  targets  to  be  serviced.  The  DJFSN  model  uses  a 
fully  connected  communications  matrix  so  that  all  elements  in  the  simulation  are 
able  to  communicate  with  each  other  (engaged  elements  can  talk  directly  with 
Joint  Fires  providers). 

The  Fire  Support  weapons  used  for  this  simulation  are  based  on  a 
generic,  battalion-  or  brigade-level  fire  support  weapon.  Currently  this  weapon  is 
155mm  artillery,  but  for  the  purposes  of  the  simulation,  the  artillery  represents  a 
joint  fires  provider  under  direction  of  the  brigade.  This  weapon  is  assumed  to 
have  sufficient  range,  accuracy  and  payload,  with  the  required  precision  targeting 
and  collateral  damage  requirements  for  use  in  an  urban  environment. 

4.3.3.3  Agent-Based  Model  Results 

MANA  results  for  blue  force  casualties  are  depicted  in  Figure  43. 
These  results  are  based  on  50  runs  of  each  alternative  within  the  specified 
scenario  and  analyzed  using  MINITAB™. 
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Analysis  of  blue  casualties  revealed  no  statistically  significant 
difference  between  the  Status  Quo  Plus  and  the  CJFSN  alternatives,  but  a 
significant  difference  between  Status  Quo  Plus  and  DJFSN  alternatives.  CJFSN 
was  expected  to  perform  better  than  the  Status  Quo  Plus  based  on  the 
assumptions  that  improved  communications  resulted  in  more  rapid  Joint  Fire 
Support  response,  and  thus  fewer  friendly  casualties.  While  investigating  the 
lack  of  improvement,  it  was  discovered  that  the  CJFSN  communications 
simulated  in  the  MANA  model  resulted  in  less  communication  between  friendly 
elements  on  a  direct  basis.  Elements  communicated  with  the  Joint  Fires  Cell  for 
fire  support  missions,  but  did  not  communicate  with  each  other  (inter-squad)  for 
those  missions  that  did  not  require  outside  fire  support.  Thus  when  the  battlefield 
environment  called  for  fewer  inorganic  fire  support  missions  the  CJFSN 
alternative  resulted  in  fewer  communications  overall,  and  a  decrease  in 
situational  awareness.  In  those  cases  where  calls  for  fire  were  frequent  and 
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necessary,  blue  casualties  decreased  and  there  were  no  differences  between  the 
DJFSN  and  CJFSN  models. 

The  DJFSN  alternative  resulted  in  the  fewest  blue  casualties. 
Based  on  the  conclusions  above,  in  a  low  calls-for-fire  environment  (organic 
target  prosecution),  situational  awareness  outside  the  squad  is  critical  to  make 
the  most  use  of  organic  assets.  In  this  environment  it  is  not  necessarily  the  Joint 
Fire  Support  process  or  format  that  facilitates  fewer  blue  casualties,  but  rather 
the  increase  in  communications  and  the  resulting  increase  in  situational 
awareness. 

The  MANA  model  was  based  on  100%  communications  accuracy. 
As  a  side  note,  sensitivity  analysis  was  conducted  within  each  alternative  to 
determine  the  effects  of  degraded  communications  accuracy.  Accuracy  was 
decreased  linearly  from  100%  to  98%  in  .2%  increments.  Casualties  increased 
exponentially  as  communications  accuracy  decreased  below  99%  for  the  Status 
Quo  Plus  alternative,  as  shown  in  Figure  44.  This  was  important  to  effective  fire 
support  in  all  alternatives,  but  critical  to  Status  Quo  Plus.  Even  a  small 
decrement  in  communications  accuracy  resulted  in  extremely  harmful  results. 
Model  behavior  included  elements  reporting  themselves  or  their  position  as 
hostile  or  fire  support  elements  firing  on  non-existent  or  stale  targets  (targets  that 
were  either  already  dead  or  that  had  moved  position).  Qn  the  other  hand, 
fratricide  due  to  communication  inaccuracies  for  both  the  CJFSN  and  DJFSN 
alternatives  appears  linear,  which  is  a  logical  result  of  a  shift  from  serial  to 
parallel  communications.  The  decrease  in  fratricide  from  distributed  to 
centralized  control  can  be  attributed  to  the  “check  and  balance”  of  multiple  users 
using  different  communications  links  to  get  the  same  information  from  one  point 
to  another,  as  well  as  the  assumed  crosscheck  of  multiple  receivers. 
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Figure  44:  Communications  Accuracy  vs.  Blue  Casualties 


In  conclusion,  the  DJFSN  alternative,  with  its  associated  web  of 
communications,  resulted  in  the  fewest  blue  casualties  (including  fratricide)  and 
best  increase  in  situational  awareness.  This  conclusion  is  valid  in  either  a  high 
volume  call  for  fires  environment,  or  an  environment  in  which  most  targets  are 
processed  organically. 


4.4  MODELING  AND  SIMULATION  SUMMARY 

The  three  proposed  alternatives  were  evaluated  based  on  the  metrics 
developed  to  support  the  effective  need.  Table  14  summarizes  the  results  from 
the  modeling  and  simulation  of  the  alternative  architectures. 
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METRICS 

Alternatives 

SQ+ 

CJFSN 

DJFSN 

1 .  Avg.  Processing  Time  for  a  Request  to  be  Serviced  (minutes) 

(i=better) 

16.7 

10.1 

6.6 

2.  Avg.  Pairing  Efficiency  of  the  Target-Weapon  Pairings  (percent) 

(t=better) 

78% 

90% 

90% 

3.  Avg.  Number  of  Systems  involved  in  the  Request-to-Tasking 

Process  (J,=better) 

10.5 

3.7 

3.8 

4.  Avg.  Number  of  Decision  Points  Involved  in  the  Request-to- 

Tasking  Process  (i=better) 

9.5 

6.9 

7.9 

5.  Avg.  Number  of  Steps  Involved  in  the  Request-to-Tasking 

Process  (J,=better) 

12.0 

9.2 

10.0 

6.  Avg.  Number  of  Gaps  in  the  Request-to-Tasking  Process 

(i=better) 

5.6 

2.1 

2.0 

7.  Avg.  Number  of  Blue  Force  Casualties 

(i=better) 

4.9 

5.1 

3.5 

Table  14:  Summary  of  Modeling  and  Simulation  Results. 


The  following  comparative  analysis  outlines  the  results  among  all 
alternatives  with  regard  to  each  criterion  previously  identified: 

1.  Time  to  process  a  CFF  request  in  simulation  was  a  surrogate  for 
proposed  system  processing  time.  Average  processing  time  for  a 
CFF  request  to  be  serviced  was  evaluated  by  simulation.  The 
results  rate  the  DJFSN  as  the  best,  followed  by  the  CJFSN 
alternative,  then  the  Status  Quo  Plus  system. 

2.  Pairing  efficiency  with  notional  weapons  effects  in  simulation  was  a 
substitute  for  an  effects-based  pairing  algorithm.  Pairing  efficiency 
was  evaluated  by  simulation.  The  average  pairing  efficiency  of  the 
Target-Weapon  pairings  rated  CJFSN  and  DJFSN  as  the  same, 
with  the  Status  Quo  Plus  performance  significantly  lower. 

3.  A  count  of  the  systems  involved  is  a  proxy  measure  to  count 
interface  translation  systems  required,  and  opportunities  for  errors 
to  be  introduced  in  the  tasking  process.  The  number  of  systems 
involved  in  the  process  was  evaluated  with  static  models.  The 
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average  number  of  systems  involved  to  generate  a  tasking  rated 
the  DJFSN  as  slightly  better  than  CJFSN  and  both  outperforming 
the  Status  Quo  Plus. 

4.  A  count  of  the  decision  points  (human  intervention)  is  a  surrogate 
measure  to  evaluate  operator  oversight,  opportunity  to  introduce 
errors,  and  process  delays  during  conversion.  The  number  of 
decision  points  involved  in  the  process  was  evaluated  with  static 
models.  The  average  decision  steps  involved  to  generate  a  tasking 
rated  the  DJFSN  best,  followed  by  CJFSN  then  Status  Quo  Plus. 

5.  A  count  of  processing  steps  is  a  substitute  for  the  volume  of 
information  exchanged  to  support  tasking  a  provider.  The  number 
of  processing  steps  (human  or  machine)  involved  in  the  process 
was  evaluated  with  static  models.  This  resulted  in  CJFSN  as 
fewest  steps,  followed  closely  by  DJFSN  and  significantly  higher 
processing  steps  in  the  Status  Quo  Plus. 

6.  A  count  of  the  process  gaps  represents  the  number  of  missing 
digital  interfaces  between  systems  in  each  alternative.  Process 
gaps  were  evaluated  with  static  models.  The  CJFSN  required  the 
fewest  followed  closely  by  DJFSN  with  Status  Quo  Plus  with  a  gap 
at  nearly  every  decision  and  processing  point. 

7.  The  organizational  and  communications  structures  modeled  in  the 
MANA  models  assessed  the  number  of  friendly  (blue)  force 
casualties  as  a  result  of  the  timeliness  of  the  response  to  a  CFF. 
The  DJFSN  communications  structure  resulted  in  the  fewest 
casualties,  and  both  the  CJFSN  and  Status  Quo  Plus  alternatives 
presented  a  similar  larger  number  of  casualties. 

Based  on  the  modeling  and  simulation  results  alone,  the  DJFSN 
alternative  offers  the  best  performance  of  system  objectives  while  fulfilling  the 
Effective  Need. 
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5.0  COST  ESTIMATE 


A  cost  estimate  for  a  system  with  few  physical  specifications  is  difficult,  if 
not  impossible.  Regardless  of  the  JFS  alternative  chosen,  the  physical  portions 
of  the  system  would  include:  user  input  devices  (such  as  TLDHS  or  “Strikelink” 
systems),  the  communications  equipment  and  architecture  necessary  to  transmit 
JFS  request  data  to  higher  command  (RF  spectrum,  TCP/IP,  SATCOM),  the 
computer  systems  and  software  necessary  to  process,  pair,  display,  and  transmit 
target  tasking  data,  and  the  associated  systems  resident  on  the  provider 
platforms. 

5.1  COST  ESTIMATE  ASSUMPTIONS 

The  basic  assumption  was  that  joint  procurement  can  be  more  economical 
and  effective  than  service-specific  acquisition.  The  overall  cost  of  a  joint 
command  and  control  system  is  expected  to  be  comparable  to  the  existing 
service  specific  C2  systems.  Table  15  summarizes  current  C2  systems  and 
illustrates  the  limited  degree  to  which  the  services  share  systems.  Shifting  to  a 
single  system  has  potential  to  reduce  expenditures  to  significantly  less  than  the 
current  total  expended  on  all  of  these  separate  systems. 


Service 

C2  system 

Contractor 

Army 

CPOF  (part  of  Maneuver  Control  System  (MCS)) 

General  Dynamics 

FBCB2/BFT 

Northrop  Grumman 

ABCS 

Lockheed 

GCCS-A 

DISA 

Navy 

TBMCS 

Lockheed 

GCCS-M 

DISA 

Air  Force 

TBMCS 

Lockheed 

GCCS-AF 

DISA 

Integrated  Space  Command  and  Control 

Lockheed 

Marine  Corps 

C2PC 

Northrop  Grumman 

Table  15:  A  Selection  of  Service  Specific  Command  and  Control  Systems 


The  other  costs  associated  with  continuing  to  operate  with  disparate  C2 
systems  is  the  lack  of  interoperability.  Four  separate  prime  contractors  maintain 
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these  systems,  with  numerous  subcontractor  support  facilities  and  teams.  The 
three  separate  GCCS  systems  are  not  currently  interoperable,  although  the 
NECC  transition  plan  does  propose  a  path  for  future  integration.^^ 

This  lack  of  interoperability  leads  to  potential  operational  costs  based  on 
mission  risk.  For  example,  if  time  sensitive  information,  delayed  due  to 
translation  from  one  services’  system  to  another,  is  used  to  dynamically 
deconflict  assets  it  could  result  in  a  higher  risk  of  fratricide.  Similarly,  delays  in 
prosecution  while  awaiting  accurate  data  for  deconfliction  or  pairing  could  result 
in  lost  opportunities  to  prosecute  valid  targets.  The  additional  risk  placed  on 
ground  elements  when  they  are  engaged  with  a  hostile  enemy  force  is 
unacceptable  when  the  source  of  the  delay  is  a  manual  translation  delay  from 
CPOF  to  TBMCS  (for  example). 

5.2  COST  ESTIMATE  CONCLUSIONS 

The  materiel  cost  of  implementing  each  alternative  is  similar.  All  involved 
elements  of:  computer  hardware,  software,  data  input  and  display  devices,  and 
radios/networking  equipment.  C2  software  requirements  for  a  common  system 
(CJFSN  and  DJFSN)  are  expected  to  be  less  than  continuing  separate 
development  with  incremental  improvements  in  interoperability  (Status  Quo 
Plus).  The  potential  operational  costs  associated  with  independent  systems  do 
not  support  future  operational  concepts  or  a  more  responsive  joint  fire  support 
system. 

In  the  end,  the  cost  of  developing  a  common  interoperable  system  is  at 
least  comparable  to  continuing  the  development  of  existing  systems.  The 
additional  operational  benefits  of  reduced  fratricide  risk  and  improved 
engagement  opportunity  provides  a  high  return  for  a  relatively  low  cost  and 
supports  development  of  a  common  command  and  control  system. 


Defense  Information  Systems  Agency,  The  NECC  Provisional  Technical  Transition 
Architecture  Specification,  Version  0.5.7,  12  April  2006,  pp.  1-2. 
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6.0  RISK  AND  RELIABILITY 


6.1  RISK  ESTIMATE 

The  magnitude  of  risk  was  estimated  by  viewing  all  three  of  the  proposed 
alternatives  from  the  perspective  of  changes  to  DoD’s  current  Doctrine, 
Organization,  Training  and  Education,  Materiel,  Leadership,  Personnel,  and 
Facilities  (DOTMLPF).  Because  some  risk  areas  crossed  DOTMLPF  categories 
the  Project  Team  combined  certain  categories  for  ease  of  discussion.  The  risks 
for  the  DOTMLPF  categories,  with  respect  to  all  three  alternatives,  are 
qualitatively  evaluated  below. 

6.1.1  Doctrinal  Risks 

This  category  considers  the  interaction  between  the  service  component 
capabilities,  the  services’  roles  and  missions,  and  Title  10.  Because  they  are 
interrelated,  especially  when  it  comes  to  the  individual  service  budgets,  the 
proposed  JFS  alternatives  pose  challenges  to  the  existing  balance  within  these 
three  areas. 

The  Status  Quo  Plus  alternative  was  assessed  to  have  a  low  risk  to 
implementation  because  it  does  not  require  a  significant  change  to  existing 
service  or  joint  doctrine  to  implement. 

However,  the  CJSFN  and  DJSFN  alternatives  require  that  service 
capabilities,  especially  those  outside  its  historical  roles,  are  considered.  This 
could  lead  to  the  expansion  of  a  particular  service’s  roles  and  missions  and  a 
possible  redistribution  of  budget.  As  an  illustration,  the  CJSFN  and  DJSFN 
alternatives  support  a  functional  consolidation  of  the  ASOC  and  the  DASC.  This 
consolidation  would  put  all  fixed  wing  CAS  assets  under  centralized  control. 
However,  Air  Force  doctrine  for  Countersea  Support  it  is  extremely  limited  (it  is  a 
single  paragraphf"^.  So,  while  Air  Force  assets  have  the  capability  to  provide 
Countersea  Support  (which  could  include  CAS  support  to  amphibious  forces),  it 

Department  of  the  Air  Force,  Air  Force  Basic  Doctrine,  AFDD-1,  17  November  2003,  pp.45-46. 
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is  easily  argued  from  a  funding  basis  that  the  Air  Force  is  not  resourced  to  fill  that 
role  and  should  not  perform  it.  This  dichotomy  exists  across  most  of  the  mission 
areas  and  affects  all  services  in  meaningful  ways. 

Additionally,  the  CJSFN  and  DJSFN  alternatives  blur  the  distinctions 
between  the  supporting  and  supported  roles.  The  concepts  of  OPCON,  TACON, 
and  ADCON  must  become  very  dynamic  to  permit  these  alternatives. 

Since  the  CJSFN  and  DJFSN  alternatives  will  undergo  continual 
rebalancing  of  capabilities,  roles  and  missions,  and  statutory  requirements,  they 
were  assessed  to  have  high  levels  of  risk  to  implementation  with  respect  to 
doctrine  as  shown  in  Figure  45. 


Figure  45:  Doctrine  Risk  Chart 


6.1.2  Organizational  and  Leadership  Risks 

This  risk  is  much  more  complex  than  simply  drawing  a  solid  or  dotted  line 
on  an  organizational  chart.  This  risk  category  considers  the  challenges  of 
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maintaining  dynamic  chains  of  command,  even  across  services,  and  the  degree 
of  business  process  reengineering  necessary  to  consolidate  cross  service 
functions.  System  and  personnel  risks  are  addressed  separately. 

The  current  movement  within  DoD  is  towards  streamlining  and 
consolidating  military  organizations  away  from  service-based  roles  and  towards 
capability-based  roles  and  missions.  While  this  move  is  in  line  with  the  effects- 
based  joint  fire  support  concept,  it  challenges  established  military  organizational 
conventions. 

The  Status  Quo  Plus  alternative  has  low  risk  to  implementation  because  it 
does  not  require  a  significant  change  to  current  fire  support  organizations. 
Because  this  alternative  preserves  existing  and  duplicate  functional 
organizations,  the  level  of  effort  required  to  execute  this  strategy  is  low. 

The  CJSFN  architecture  was  assessed  to  have  a  medium  risk  level  due 
because  it  requires  the  consolidation  of  HQ-level  organizations  with  similar  roles. 
Combining  the  functionally  similar  organizations  with  different  cultures  and 
procedures  will  require  extensive  process  engineering  efforts.  It  does  not 
fundamentally  change  the  organizational  construct  of  JFS  to  the  same  degree 
that  the  DJFSN  alternative  does. 

The  DJSFN  alternative  was  assessed  to  have  a  high  level  of  risk  due  to 
the  significance  and  scope  of  the  organizational  changes  required  to  implement 
it.  Because  Distributed  JFS  organizations  are  networked  at  all  levels,  from  the 
field  to  the  JQC,  the  dynamic  chains  of  command  and  shifting  levels  of  authority 
will  challenge  conventional  leadership  concepts.  A  transition  to  a  Distributed 
JFSN  organizational  construct  would  be  difficult  to  implement  incrementally  and 
the  initial  performance  of  the  Distributed  architecture  will  probably  be  less  than 
projected  until  leadership  style  adjustments  are  assimilated  throughout.  The 
organization  and  leadership  risks  of  each  alternative  are  shown  in  Figure  46. 
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Figure  46:  Organization  and  Leadership  Risk  Chart 

6.1.3  Tactics  and  Training  Risks 


This  category  highlights  the  risk  involved  with  creation  and  implementation 
of  completely  joint  tactics  and  training  procedures  with  respect  to  JFS.  These 
risks  include  implementation  at  the  forward  observer  level  and  at  the  upper- 
echelon  levels.  The  Status  Quo  Plus  alternative  was  assessed  to  have  a  low  risk 
to  implementation  due  to  the  limited  changes  from  current  and  projected  tactics 
and  training.  The  service-specific  improvements  to  JFS  associated  systems  and 
procedures  will  incur  a  minimal  training  burden  on  the  service  components 
without  any  significant  changes  to  tactics  and  only  slight  improvements  in  tactical 
flexibility.  There  will  continue  to  be  a  burden  for  cross-service  training  of  liaison 
elements  in  the  disparate  C2  systems  of  each  service.  There  are  no 
requirements  to  further  standardize  call  for  fire  formats  or  data  standards  in  the 
Status  Quo  Plus  alternative,  therefore  those  training  requirements  change  very 
little. 
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The  CJFSN  alternative  was  assessed  to  have  a  medium  risk  to 
implementation  with  respect  to  tactics  and  training.  The  movement  towards  a 
common  JFS  data  entry  and  request  device  and  C2  system  will  enable 
standardization  of  warfighter  training  requirements  across  all  of  the  services. 
This  commonality  of  equipment  should  enable  significant  improvements  in 
training  quality  and  tactical  flexibility,  and  the  risk  will  be  mitigated  by  maintaining 
the  option  to  use  legacy  voice  procedures  for  requesting  support.  One  of  the 
most  significant  risks  to  this  alternative  with  respect  to  training  is  the 
development,  acceptance,  and  implementation  of  a  common  joint  call  for  fire 
format  to  replace  the  numerous  service  and  function-specific  formats  used  today. 
The  changes  in  the  routing  of  this  request  are  anticipated  to  produce  noticeable 
improvements  in  upper-echelon  functions  as  a  result  of  organizational 
consolidation  moves  such  as  the  Joint  Fires  Cell.  The  simple  act  of  consolidating 
cross-functional  expertise  should  realize  efficiency  gains  in  both  coordination  and 
processing  times,  but  also  in  the  tactical  efficiency  of  the  request-to-provider 
pairings.  The  training  risks  of  consolidation  at  this  level  are  mitigated  by  virtue  of 
the  breadth  of  experience  available  for  on-the-job  training  and  learning,  although 
there  may  be  some  tactical  challenges  with  initial  implementation  and  use  of  a 
common  format  for  request  for  fire  data. 

The  DJFSN  alternative  was  assessed  to  incur  a  high  level  of  training  risk 
due  to  shifts  in  authority  and  responsibility.  The  ability  to  request  and  receive  fire 
support  without  direct  oversight  and  approval  requires  a  high  degree  of  individual 
proficiency.  The  movement  towards  a  common  JFS  data  entry  and  request 
device  and  C2  system  will  enable  standardization  of  warfighter  training 
requirements  across  all  of  the  services.  The  training  burden  for  tactical  expertise 
and  aptitude  is  shifted  from  a  relatively  small  cadre  of  upper-echelon  leaders  to  a 
very  large  group  in  the  field  and  in  combat.  The  responsiveness  of  this 
architecture  will  challenge  the  ability  of  supervisory  entities  to  maintain  tactical 
synergy  and  deconfliction  of  fires.  A  risk  reduction  factor  of  this  alternative  could 
be  that  the  elimination  of  service  or  function  specific  equipment  will  remove  the 


129 


premium  currently  placed  on  training  for  those  specialized  systems.  The  tactics 
and  training  risks  of  each  alternative  are  shown  in  Figure  47. 
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Figure  47:  Tactics  and  Training  Risk  Chart 

6.1.4  Materiei  Risks 


The  main  risk  drivers  in  this  area  are  system  interoperability  and  the 
expanded  vulnerability  of  a  fully  networked  force.  Interestingly,  technical 
readiness  levels  were  not  determined  to  be  a  driver.  The  core  technologies  to 
develop  fully  interoperable  JFS  systems  exist  today.  Interoperability  challenges 
reside  primarily  with  programmatic  choices. 

System  interoperability  includes  the  equipment  which  processes  the  call 
for  fire  directly  (fielded  land,  sea,  and  air  systems),  the  C2  systems  which  provide 
decision  inputs,  and  the  communications  structure  (GIG)  which  serves  as  the 
information  conduit. 
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There  is  a  continuum  of  interoperability  that  will  define  the  materiel  risks  of 
the  three  alternatives.  The  highest  level  of  interoperability  occurs  when  there  is 
complete  commonality  of  equipment  or  the  systems  have  been  purposefully 
developed  to  be  interoperable.  On  the  other  end  of  the  spectrum,  the  lowest 
level  of  interoperability  occurs  when  the  interface  between  separate  systems  or 
functions  is  filled  by  a  person  that  must  combine  or  move  data  from  one  system 
to  another.  The  interoperability  required  of  the  systems  and  material  needed  to 
implement  the  alternatives  drives  the  risk  for  each. 

Expanded  system  vulnerabilities  stem  from  the  assumption  of  network 
connectivity.  All  networked  nodes  in  these  joint  fire  support  request  networks 
can  be  assumed  to  be  predictably  radiating  within  the  electromagnetic  spectrum. 
Radiating  nodes  lose  the  advantage  of  concealment.  Additionally,  attacks 
against  radiating  nodes  would  likely  result  in  a  “no  transmit”  policy,  rendering  all 
of  the  proposed  alternatives  ineffective.  This  risk  will  have  to  be  mitigated 
through  technology  (low  power  signals)  and  countermeasures.  Since  a  net- 
enabled  force  was  an  assumed  condition  across  all  alternatives,  this  risk  was 
assessed  to  be  equal  for  all  alternatives. 

The  Status  Quo  Plus  alternative  incurred  low  materiel  risk  because  it 
accepts  a  low  level  of  interoperability.  Projected  improvements  to  the  separate 
C2  systems  at  upper  command  levels  will  enhance  the  performance  of  these 
alternatives,  but  the  repercussions  of  failures  in  interoperability  at  these  levels 
will  be  absorbed  by  personnel.  While  its  fire  support  networks  will  require 
relatively  faster  and  more  efficient  communications,  most  of  the  communications 
strain  in  this  alternative  will  be  across  the  upper  organizational  echelons. 
Incremental  improvements  in  legacy  C2  systems  and  currently  fielded  data  input 
devices  (service  and  function  specific)  will  reduce  this  alternative’s  risk. 

Both  the  CJFSN  and  DJFSN  alternatives  were  assessed  to  have  medium 
levels  of  risk.  Both  of  these  alternatives  require  significant  interoperability  in  order 
to  function.  Both  alternatives  require  fully  interoperable  C2  systems,  the 
development  and  DoD-wide  fielding  of  a  joint,  common  input  data  device,  and  a 
common  transmission  network  that  eliminates  specialized  data  links,  particularly 
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across  the  aircraft  fleets.  These  alternatives  demand  improvements  in 
communications  and  networking  although  the  requirements  for  the  Centralized 
alternative  are  primarily  on  the  back  side  of  the  request  (in  the  processing  and 
tasking  areas).  The  network  requirements  for  the  DJFSN  are  riskier  because 
connectivity  must  span  all  organizational  levels  and  out  to  the  “edge”  with  the 
forward  observer.  The  materiel  risks  of  each  alternative  are  shown  in  Figure  48. 
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Figure  48:  Materiel  Risk  Chart 


6.1.5  Personnel  and  Facility  Risks 

The  risks  to  implementation  of  these  alternatives  due  to  personnel  and 
facility  changes  vary  significantly.  The  Status  Quo  Plus  alternative  is  assessed 
to  have  very  little  risk  because  the  qualified  personnel  and  appropriate  facilities 
needed  to  implement  this  option  already  exist.  Although  there  may  be  some 
challenges  caused  by  incremental  improvements  of  legacy  systems,  the  risk 
remains  small  in  this  category. 
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The  CJFSN  concept  will  make  significant  demands  on  physical  facilities 
due  to  the  consolidation  of  fire  support  functions  and  personnel.  This  was 
assessed  as  a  medium  level  of  risk  and  can  be  mitigated  by  simply  mixing  the 
personnel  and  expertise  currently  segregated  by  function  and  service  without 
combining  them  into  one  large  organization. 

The  DJFSN  alternative  will  incur  high  risk  to  implementation  due  to  the 
fundamental  personnel  changes  involved.  The  ability  to  transition  the  tactical 
knowledge  and  experience  in  JFS  into  a  virtual  and  distributed  organization  at 
the  level  of  proficiency  required  is  not  currently  feasible.  Although  the  relaxation 
of  physical  facility  requirements  helps  reduce  the  implementation  risk,  the 
personnel  productivity  of  virtual  organizations  must  also  meet  or  exceed  the 
capability  of  a  co-located  organization.  This  will  be  very  risky  if  a  large  portion  of 
that  virtual  organization  is  on  the  battlefield  under  fire.  The  personnel  and 
facilities  risks  of  each  alternative  are  shown  in  Figure  49. 
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Figure  49:  Personnel  and  Facilities  Risk  Chart 


A  summary  comparison  of  the  qualitative  risk  estimates  of  these 
alternatives  is  provided  in  Figure  50  and  Table  16. 
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Figure  50:  Summary  Risk  Chart 


Status  Quo  Plus 

Centralized  JFSN 

Distributed  JFSN 

Doctrine 

No  Significant 
Changes 

Transition  from  Service 
Doctrine  to  Joint 

Integrated  and  Altered 
Joint  Doctrine 

Organization 

& 

Leadership 

No  Significant 
Changes 

Consolidation  of  Orgs. 
with  Similar  Roles 

Dynamic,  Virtual 
Command  Structures 

Training  & 

No  Significant 

Common  Joint  Tactics 

Tactical  Delegation  of 

Tactics 

Changes 

and  Training 

Authority,  Taskings 

Material 

No  Significant 
Changes 

Core  C2  System 
Interoperability 

Total  C2  Interoperability 
to  the  “Edge” 

Personnel  & 
Facilities 

No  Significant 
Changes 

Cross-functional  Orgs. 

Virtual  Orgs.  and 
Disconnected  Personel 
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Table  16:  Risk  Across  Alternatives  with  Respect  to  DOTMLPF 

6.2  RELIABILITY  ESTIMATE 

Each  alternative’s  performance  of  F2T2EA  functions  forms  a  basis  for 
future  reliability  analysis.  The  proposed  joint  fires  system  fits  the  process 
between  acquiring  targets  (find,  fix,  and  track)  and  prosecuting  them  (engage 
and  assess).  Evaluating  potential  failure  modes  and  mission  impact  of  each  step 
in  the  process  provided  insight  into  what  failures  significantly  degrade  overall 
system  operation.  The  Project  Team  examined  specific  failure  modes  and 
assessed  severity  and  likelihood  for  each  alternative.  These  failure  modes  were 
evaluated  relative  to  the  severity  of  the  mission  and  were  independent  of  the 
system  alternative.  The  likelihood  of  occurrence  based  on  the  alternative 
implemented  was  then  evaluated.  A  relative  risk  assessment  code  was  then 
assigned  and  color  code  ratings  listed  for  each  failure  mode  (as  seen  on  Tables 
17,  18,  and  19).  The  list  is  not  all  inclusive  and  the  severity  is  will  be  mission 
(scenario)  dependent. 

The  definition  of  what  constitutes  a  failure  is  necessary  to  evaluate  the 
overall  system.  Failure  to  deliver  available  ordnance  on  a  valid  target  is 
considered  a  failure  of  the  overall  fires  system.  Figure  51  summarizes  the  overall 
system,  with  potential  failures  listed. 


Figure  51 :  Overall  Fires  System  Potential  Failures 
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The  acquire  and  prosecute  processes  are  outside  the  scope  of  the  system 
being  developed,  but  potential  failures  at  those  interfaces  are  important  to  the 
overall  reliability  of  the  system.  Reliability  risks,  failure  modes  and  potential  for 
mitigation  are  discussed  below. 

6.2.1  Request  Process  Failures 

The  request  input  from  the  forward  observer  or  other  engaged  unit  was 
assumed  to  be  perfect  within  the  team’s  modeling  and  simulation.  The  main 
causes  of  errors  being  introduced  to  the  system  by  the  request  are  equipment 
failure,  environmental  effects,  and  training. 

Table  17  summarizes  some  potential  failures  and  proposes  actions  to 
mitigate  the  risk  of  invalid  or  missed  requests.  Equipment  failures,  such  as  the 
primary  radio,  typically  result  in  delays  in  placing  the  CFF.  Additional  radios  are 
typically  available  within  the  unit,  the  request  can  be  sent  to  another  unit  for 
forwarding,  or  messengers  can  be  sent. 

Environmental  effects,  including  radio  interference,  or  electronic  attack 
may  prevent  a  call  from  being  sent  or  merely  delayed  while  an  alternative 
communications  path  is  found. 

The  final  factor,  human  error  is  typically  a  result  of  insufficient  training  or 
proficiency.  Correctly  identifying  a  target  while  under  fire  can  be  difficult.  There 
is  a  tendency  to  request  destruction  of  every  target.  This  typically  is  not  the 
commander’s  intent  because  excessive  ordnance  and  providers  could  be  tasked 
potentially  missing  other  valid  targets. 

Additionally,  blind  reliance  on  targeting  equipment  without  the  experience 
to  verify  the  data  can  lead  to  precision  errors.  Unqualified  observers  calling  for 
fire  on  their  position,  not  recognizing  range  or  bearing  errors,  and  calling  from  the 
wrong  reference  point  will  have  severe  implications.  Tasking  a  qualified  fire 
support  team  to  respond  to  every  call  may  not  be  feasible. 
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Potential  Failure 

Mode 

Potential 

Causes 

Mission 

Impact 

Recommendations 

Results 

1  Risk  to  Mission  | 

SQ+ 

CJFSN 

DJFSN 

Request  Not 
Received 

FO  radio 
failure 

Valid  target  not 
nominated 

Alternate  comm  path 

Additional  delay 

Med 

Med 

Med 

Request  Not 
Received 

Environment 

(blockage) 

Valid  target  not 
nominated 

Multi  frequencies 

Increased  cost, 
weight  or  quantity 
of  radios 

Med 

Med 

Med 

Request  Not 
Received 

Jamming 

Valid  target  not 
nominated 

HOJ  asset  tasking 

Reduced  providers 
for  other  missions 

Med 

Med 

Med 

Precision  Error 

FO  precision 

Precisely  miss 
target 

Reliable  positioning  and 
targeting  equipment 

Increased  weight, 
possibly  requires 
vehicle 

High 

Med 

Med 

Wrong  Effects 

FO  training 
and 

experience 

Overkill  -  lost 
opportunity  to 
prosecute 
harder  target 

Joint  training  on  desired 
effects 

Expect  request  for 
overkill  from  all  non 
trained  requesters 

Med 

Low 

Low 

Table  17:  Potential  Failures  in  the  Acquire  Process 

6.2.2  Targeting  Process  Failures 

The  targeting  process  for  each  alternative  is  the  primary  system  under 
consideration.  A  summary  of  the  potential  failures  in  this  system  are  presented 
in  Table  18.  Equipment  failures  and  human  error  account  for  the  majority  of 
potential  problems. 
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Potential  Failure 

Mode 

Potential 

Causes 

Mission 

Impact 

Recommendations 

Results 

1  Risk  to  Mission  | 

SQ+ 

CJFSN 

DJFSN 

Tasking  Not 
Received 

Decision 
authority  fails 
to  transmit 

Valid  target  not 
engaged 

Alert  decision  authority 
of  delay 

Requires  (semi-) 
automated 
decision  aid 

High 

Med 

Low 

Request  Not 
Prosecuted 

No  assets 
available 

Valid  target  not 
engaged 

Alert  decision  authority. 

Possible  re-tasking 
of  assets 

Med 

Med 

Med 

Request  Not 
Prosecuted 

Priority  too 
low 

Valid  target  not 
engaged 

Inform  FO 

Possible  re-tasking 
of  assets  or  delay 
in  engagement 

Med 

Med 

Med 

Request  Not 
Prosecuted 

Insufficient 

time 

Increased  risk 
to  engaged 
forces 

Inform  FO,  update  TOT 

Delay  or  cancel 
request 

Med 

Med 

Med 

Request  Not 
Prosecuted 

COP 
indicated 
danger  close 
(or  denied 
target) 

Increased  risk 
to  forces 

Inform  FO,  verify 
positions  and  update 
COP 

Cancel  request, 
delay  in 
engagement  if 
request  deemed 
valid 

Med 

Low 

Med 

Delivery  Late 

Delay  in  asset 
availability 

Partial  Success 
(hit  late) 

Inform  FO 

Delay  or  loss  of 
engagement 

Med 

Low 

Low 

Delivery  Late 

Estimated 
time  on  top 
too  late 

Failure  (target 
departed) 

Inform  FO,  task  earliest 
provider 

Delay  or  loss  of 
engagement 

Med 

Med 

Med 

Delivery  Late 

Excessive 
pairing  time 

Delay  in 
authority  to 
task 

Delegate  to  appropriate 
level 

Less  CDR 
involvement  in 
decision  process, 
ROE  may  restrict 

High 

Med 

Low 

Precision  Error 

Error  in 

message 

transmission 

Attack  wrong 
target 

Data  structure  design, 
verification  of  task  with 
requester 

Increased 
message  flow, 
bandwidth 
requirements 

Med 

Med 

Med 

Wrong  Effects 

Pairing 

algorithm 

errors 

Target  requires 
re-attack 

JFC  staff  periodically 
evaluate  algorithm  for 
current  CDR  intent 

Variety  of  pairing 
algorithms  based 
on  ROE  &  CDR 
Intent 

Low 

Low 

Low 

Wrong  Effects 

Pairing 

algorithm 

errors 

Target  requires 
re-attack 

Exercise  evaluate 
algorithms 

Modeling  and 
simulation  of 
algorithms  prior  to 
operational  use 

Low 

Low 

Low 

Wrong  Effects 

Ordnance 
load  not 
correct  in 

COP 

Overkill  or 
under  kill 

Auto  update  weapon 
platform  status  in  COP 

Lost  opportunity  or 
re-attack  required 

Med 

Med 

Low 

Tasking  Not 
Received 

Provider  radio 
failure 

Valid  target  not 
engaged 

Alternate  comm  path  or 
alternate  provider 

Delay  in 
engagement  or 
"2nd  best"  provider 
tasked 

Med 

Med 

Low 

Tasking  Not 
Received 

Environment 

(blockage) 

Valid  target  not 
engaged 

Multi  frequencies 

Delay  in 
engagement  or 
"2nd  best"  provider 
tasked 

Med 

Med 

Med 

Table  18:  Potential  Failures  in  the  Joint  Fires  System  Targeting  Process 

Communications  system  failures  may  prevent  requests  from  being 
forwarded  to  the  appropriate  decision  cell  or  tasking  orders  being  sent  to 
providers.  In  either  case,  a  delay  in  engagement  or  loss  of  target  will  result. 
Failures  in  communication  with  the  common  operational  database,  or  within  the 
database  itself  will  complicate  the  pairing  and  deconfliction  algorithms. 
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Assignments  to  less  than  optimal  providers  or  an  increase  in  “CANTCO” 
responses  will  result.  Delays  in  prosecution  due  to  manual  deconfliction  of 
airspace,  or  increased  risk  of  fratricide  will  also  result.  The  algorithms  used  for 
pairing  and  deconfliction  should  account  for  the  possibility  of  time  delayed 
position  data  and  the  application  of  appropriate  separation  for  assets  and 
ordnance  trajectories. 

These  pairing  and  deconfliction  algorithms  also  require  flexibility  to  meet 
changing  Commander’s  Intent  and  Rules  Of  Engagement.  The  correct  pairing  in 
an  open  desert  permissive  environment  is  not  necessarily  the  same  as  a 
constrained  urban  setting  even  when  the  same  assets  are  available.  The  JFC 
staff  should  periodically  review  the  algorithm  in  use  and  promulgate  changes  to 
subordinate  commands. 

The  message  format  and  data  structure  used  to  share  the  information 
between  the  various  entities  should  be  robust  enough  to  be  virtually  error  free. 
Inadvertent  bit  errors  that  go  undetected  will  adversely  impact  the  engagement 
process.  Increased  risk  of  fratricide,  collateral  damage,  and  lost  opportunities  to 
engage  targets  will  result. 

Errors  in  the  operational  picture  will  increase  the  risk  to  blue  and  neutral 
forces  or  may  negate  a  valid  CFF.  Sharing  this  data  with  coalition  forces 
presents  a  significant  security  risk  that  should  be  addressed  separately. 

Unavailability  of  assets  or  an  estimated  engagement  beyond  requested 
response  time  needs  to  be  communicated  to  the  operational  commander  and  the 
requesting  unit.  A  decision  will  then  be  made  to  engage  the  target  when  an 
asset  becomes  available,  cancel  the  request,  or  re-task  an  asset  assigned  to  a 
lower  priority  target.  The  Project  Team’s  modeling  and  simulations  did  not 
consider  a  situation  where  preplanned  missions  were  re-tasked  to  engage 
unplanned  targets. 
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6.2.3  Prosecution  Process  Failures 


Table  19  summarizes  potential  failures  during  the  prosecution  process. 
Project  Team  simulation  and  modeling  did  not  take  into  account  potential  failures 
which  include  equipment  failures,  environment  effects,  and  human  error. 


Potential  Failure 

Potential 

Mission 

Recommendations 

Results 

1  Risk  to  Mission  | 

Mode 

Causes 

Impact 

SQ+ 

CJFSN 

DJFSN 

Tasking  Not 
Received 

Jamming 

Valid  target  not 
engaged 

HOJ  asset  tasking 

Reduced  providers 
for  other  missions 

Med 

Med 

Med 

Delivery  Late 

Operator 
intervention 
required  or 
error  in 
delivery 

Increased  risk 
to  engaged 
forces 

COP  update  sufficient 
to  use  auto-deconflict 
algorithms 

Increased 
message  flow, 
bandwidth 
requirements 

Med 

Med 

High 

Delivery  Late 

Manual 

deconfliction 

required 

Increased  risk 
to  engaged 
forces 

COP  update  with  all 
friendly  assets 

Manual  or  auto 
update  own  unit 
status  periodically 

Med 

Med 

High 

Precision  Error 

Target  close 
to 

friendly/neutr 
al  types 

Risk  of  CDE  / 
Fratricide 

Danger  close  range 
restrictions  included  in 
pairing  algorithms 

TTPs  for  engaging 
danger  close 
targets  still 
required.  Limits 
potential  providers 

High 

High 

High 

Precision  Error 

Targeting 
error  at 
delivery 

Target  requires 
re-attack 

Function  of  weapon- 
platform 

Pairing  algorithm 
consider  effects 
based  on  platform- 
weapon  effects 

Med 

Med 

Med 

Table  19:  Potential  Failures  in  the  Prosecution  Process 

Environmental  interference  or  jamming  preventing  receipt  of  tasking  can 
be  mitigated  by  tasking  the  “second  best  asset”  or  providing  anti-jam  or  electronic 
attack  assets  to  engage  the  jammer.  A  delay  in  engagement  or  loss  of 
opportunity  to  engage  the  target  may  result. 

Equipment  failure  of  the  provider  will  result  in  a  non-engagement,  and 
require  the  target  to  be  re-assigned.  Removal  of  the  asset  as  a  potential  provider 
from  the  operational  database  should  make  this  a  single  event  with  minimal 
overall  system  impact.  Inherent  inaccuracies  in  the  targeting  systems  (position 
error,  circular  error  probable,  average  miss  distance,  etc.)  will  impact  the  actual 
effectiveness  and  coupled  with  effective  assessment  may  require  re-nomination 
of  the  target  for  prosecution. 
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System  errors  that  require  human  intervention  will  typically  delay  time  until 
the  target  is  engaged.  If  the  CAS  provider  is  required  to  deconflict  airspace  via 
voice  en  route  to  the  target,  the  overall  timeliness  of  response  will  suffer.  For 
“Danger  Close”  targets,  it  will  be  required  to  employ  tactics  and  procedures  that 
are  inherently  more  difficult  and  slower  than  a  less  restrictive  CFF. 

The  overall  expected  risk  of  the  above  failures  can  be  used  to  rank  the 
alternatives  based  on  relative  reliability  of  mission  success.  The  Acquire  process 
rated  the  Status  Quo  Plus  more  likely  to  fail  than  the  centralized  and  distributed 
joint  fire  support  networks.  The  Target  process  rated  the  DJFSN  alternative  as 
the  best,  followed  by  the  CJFSN  and  Status  Quo  Plus.  The  Prosecution  process 
rated  the  Status  Quo  Plus  and  CJFSN  as  moderate  to  high  risk,  with  the  DJFSN 
even  higher. 


142 


7.0  RESULTS  AND  CONCLUSIONS 


The  objective  of  this  study  was  to  determine  a  better  way  to  perform  Joint 
Fire  Support.  Specifically,  the  Project  Team  attempted  to  “define  an 
operationally  feasible  Joint  Fire  Support  request,  coordination,  and  tasking 
architecture  that  maximizes  rapid  battlefield  effects  for  the  Commander.”  By 
taking  an  objective  look  at  the  concept  of  JFS  and  applying  a  systematic  design 
process  to  the  problem,  the  project  team  has  identified  challenges,  proposed 
solutions,  and  insights  for  a  truly  “joint”  fire  support  system  in  the  future. 

7.1  PREFERRED  SYSTEM  ARCHITECTURE 

The  Distributed  alternative  offers  the  best  possible  range  of  benefits  but 
also  comes  with  the  highest  implementation  risks  and  challenges.  Before  the 
project  team  could  arrive  at  an  overall  alternative  recommendation,  a 
consideration  that  military  forces  will  have  to  continue  day-to-day  operations 
during  the  transition  period.  This  constrained  the  risk  that  operational 
commanders  would  wish  to  take  and  imposed  a  “tipping  point”  for 
implementation.  Having  considered  all  these  factors,  the  team  chose  to 
recommend  the  distributed  joint  fires  support  network  as  the  recommended 
alternative.  However,  the  project  team  recommended  against  efforts  to  get  to 
that  objective  in  one  step.  The  Centralized  alternative  is  a  natural  evolutionary 
step  to  get  to  a  distributed  system.  Moving  to  the  centralized  alternative  and, 
after  that  alternative  is  fully  realized,  moving  to  the  distributed  architecture  is  a 
preferred  method  to  mitigate  implementation  risk. 

The  doctrine,  organization,  and  materiel  requirements  for  the  DJFSN 
system  drive  the  main  sources  of  operational  risk.  The  dynamic  chains  of 
command,  a  fully  interoperable  and  common  command  and  control  system,  and 
trusted  decision  making  algorithms  are  high  risk  to  implement;  the  DJFSN 
system  fails  without  them.  However,  even  though  these  objectives  will  be  difficult 
to  implement,  they  should  remain  the  ultimate  goals. 
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The  Centralized  Joint  Fire  Support  Network  (CJFSN)  represents  a 
stepping  stone  on  the  path  to  DJFSN.  While  CJFSN  also  streamlines  chains  of 
command  and  requires  an  interoperable  command  and  control  system,  it  remains 
less  efficient  than  DJFSN  because  it  keeps  the  personnel  associated  with 
decision-making  at  the  various  functional  levels.  These  people  are  the  key  to 
operational  risk  mitigation;  they  can  absorb  the  shortfalls  associated  with  areas 
that  do  not  yet  meet  the  larger  goals. 

The  path  to  implementing  a  fully  distributed  joint  fire  support  network  can 
be  achieved  by  transitioning  first  to  a  centralized  joint  fire  support  network 
(CJFSN)  and  then  building  on  that  success.  Development  of  the  required 
doctrine,  organization,  and  tactics  changes  will  then  allow  a  “top-down” 
implementation  of  the  DJFSN.  This  “build  a  little,  test  a  little”  approach  will 
mitigate  the  risks  involved  with  transition  from  Status  Quo  (Plus)  to  a  fully 
distributed  process  while  also  improving  overall  Joint  Fires  system  performance. 

The  magnitude  of  DOTMLPF  changes  required  to  implement  the  DJFSN 
alternative  compared  to  the  centralized  or  status  quo  plus  is  illustrated  in  Figure 
52. 
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Figure  52:  Potential  Benefits  and  Risks  of  the  Proposed  Alternatives 


7.2  CONCLUSIONS  AND  RECOMMENDATIONS 


There  are  numerous  obstacles  that  must  be  overcome  if  any  integrated 
JFS  system  is  to  be  deployed.  Based  on  the  team’s  study  of  the  challenges  of 
joint  fire  support  and  the  recommended  implementation  path  from  a  centralized 
to  a  distributed  joint  fire  support  network,  numerous  recommendations  were 
identified  to  enable  this  change.  These  conclusions  and  recommendations  have 
been  organized  in  the  construct  of  the  DOTMLPF  model  and  are  highlighted 
below. 


7.2.1  Doctrinal  Conclusions  and  Recommendations 

The  implementation  of  the  DJFSN  requires  that  service  doctrine  continues 
to  evolve  towards  capability-based  operations.  Progress  in  this  area  has  been 
significant  and  is  likely  to  continue.  The  establishment  of  the  JFC  structure  has 
brought  an  unprecedented  level  of  flexibility  to  operations.  And  commands  like 
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SOCOM  continue  to  push  out  “the  edges  of  the  envelope”  through  their  day-to- 
day  operations. 

The  Joint  Fires  Support  mission  area  crosses  the  boundaries  of  the 
four  Services,  each  bringing  unique  capabilities  to  the  battle.  The 
synergism  of  the  mission  area  that  has  universal  Tactics, 
Techniques  and  Procedures  (TTPs),  recognized  and  employed  by 
all  users,  will  be  a  force  multiplier  for  joint  operations  in  the  future.^^ 


Doctrine  should  also  permit  the  services  to  carry  more  supporting  roles 
and  missions  that  are  consistent  with  their  capabilities  and  Title  10 
responsibilities.  In  particular,  doctrine  should  establish  more  developed  ground 
and  air  combat  support  relationships  among  the  services. 


7.2.2  Organizational/Leadership  Conclusions  and  Recommendations 

Functionally  equivalent  organizations  should  be  consolidated,  physically  or 
virtually,  with  formal  organizational  linkage  under  the  JFC  construct.  From  the 
perspective  of  the  team,  there  are  a  significant  number  of  organizations 
performing  comparable  functions.  For  example,  the  DASC  and  ASOC  complete 
many  of  the  same  tasks  for  CAS  operations.  Defined  organizational  links  will 
maintain  clear  chains  of  command  and  allow  any  calls-for-fire  to  move  between 
the  services’  decision  nodes  without  having  to  transit  the  staffs,  thereby 
shortening  the  timeline  for  truly  effects-based  decision  making. 

This  organizational  consolidation  should  be  used  as  the  catalyst  for 
functional  collaboration.  Personnel  working  in  these  organizations  will  expose 
the  interoperability  issues  of  duplicative  systems,  help  develop  common  training 
syllabi,  and  be  a  primary  source  of  cross-cutting  improvements.  Acting  on  these 
areas  is  key  to  the  “build  a  little,  test  a  little”  approach  and  overall  implementation 
success. 


U.S.  Marine  Corps  Marine  Corps  Combat  Development  Command,  Mission  Area  Initial 
Capabilities  Document  for  Close  Air  Support,  JROCM  095-04,  14  June  2004,  p.  2. 
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7.2.3  Tactics  and  Training  Conciusions  and  Recommendations 

Develop  a  core  syllabus  of  standardized,  joint  training  for  calls-for  fire 
which  is  included  in  every  service’s  basic  combat  skills  list.  Where  it  is 
necessary,  specialized  training  for  fire  support  teams,  forward  observers,  forward 
air  controllers,  or  riverine  combat  teams  may  be  developed.  The  expected  result 
is  a  reduction  of  training  differentiation  between  the  services  and  consistent 
procedures  between  theaters.  Develop  a  common  joint  tactical  publication  set  to 
reinforce  this  core  syllabus. 

Develop  prioritization,  pairing,  and  deconfliction  algorithms  for  a  variety  of 
scenarios.  These  automated  algorithms  will  be  used  as  tactical  aides  by  the 
Joint  Fires  Cell  to  support  rapid  effects-based  pairing.  A  robust  set  of  algorithms 
that  can  be  tailored  to  support  the  JFC  intentions  and  operational  requirements  is 
necessary  to  move  to  the  DJFSN  architecture. 

7.2.4  Materiel  Conclusions  and  Recommendations 

The  DoD  must  realign  to  permit  the  development  of  interoperable 
systems.  With  respect  to  joint  fires,  this  realignment  must  focus  on  the  portfolios 
of  programs  that  comprise  the  Command  and  Control  systems,  fielded  ground, 
air,  and  ship  systems,  and  the  communications  equipment  which  comprises  the 
Global  Information  Grid.  Despite  the  significant  efforts  from  a  roster  of  program 
executive  officers,  functional  boards,  and  oversight  councils,  separate  command 
and  control  systems  still  exist  within  a  fractured  community.  Each  service 
maintains  multiple  approaches  to  address  common  issues.  This  diversity 
extends  across  the  entire  joint  fire  support  spectrum  and  is  increasing  each  day. 
For  example,  as  the  “ground  gets  taller”  with  fielded  combat  troops  operating 
UAVs  in  the  battlespace,  integration  into  the  Theater  Battle  Management  Core 
System  (TBMCS)  is  not  a  requirement  for  the  UAV  C2  systems. 

The  DoD  should  realign  the  requirements,  authority,  and  funding  of  the 
programs  into  a  single  track.  One  construct  to  do  this  is  to  use  a  Joint  Program 
Executive  Officer  as  the  instrument  of  that  change.  For  C2,  this  would  be 
particularly  difficult  since  the  acquisition  community  is  divided  between  the 
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Assistant  Secretary  of  Defense  for  C3I  and  each  of  the  services.  With  fully 
interoperable  systems  as  the  goal,  all  systems  which  process  calls-for-fire  should 
share  common  data  standards;  many  of  which  already  exist.  As  an  example,  the 
Joint  C3  Information  Exchange  Data  Model  (JC3IEDM)  developed  by  the 
Multilateral  Interoperability  Program  (MIP)  at  NAVSEA  is  a  mature  standard  but  it 
has  not  yet  been  widely  used  outside  experimental  settings. 

The  DoD  should  continue  investments  in  communications  with  an 
emphasis  on  providing  more  bandwidth  to  the  fielded  troops,  ships,  and  aircraft. 
Much  like  the  C2  discussion  above,  the  Global  Information  Grid  (a  program 
managed  by  DISA  under  ASD/C3I)  needs  to  move  in  step  with  the  services’  own 
planned  networks.  The  Navy’s  ForceNet,  Air  Force’s  C2  Constellation,  and 
Army’s  LandWarNet  systems  are  attempting  to  capture,  process,  interface,  and 
secure  the  ever-increasing  amount  of  networked  tactical  data  in  the  form  of  text, 
VoIP,  recorded  data,  sensor  targeting,  fire  control  data,  text  command 
instructions,  and  images.^®  The  command  and  control  efficiency  needed  to 
effectively  communicate  the  JTF  commander’s  intent  and  priorities  will  be 
impossible  to  achieve  without  a  robust  and  interoperable  system. 

The  DoD  should  designate  a  “Center  of  Excellence”  for  the  development 
of  the  family  of  decision  algorithms  necessary  to  support  automated  command 
and  control.  Throughout  this  thesis,  the  Project  Team  reviewed  several  decision 
algorithms  that  conducted  various  actions  including  prioritization,  pairing,  and 
resource  deconfliction.  The  team  concluded  that  no  universal  decision  making 
algorithm  will  satisfy  the  full  range  of  operational  requirements.  However,  the 
majority  of  these  algorithms  will  share  common  processes  and  data 
requirements.  A  centralized  repository  of  methods  and  expertise  should  prevent 
needless  duplication  in  this  area. 

7.2.5  Personnel  and  Facility  Conciusions  and  Recommendations 

The  continued  development  of  the  Global  Information  Grid  (GIG)  should 
allow  the  expansion  of  the  joint  fire  support  concept  within  the  US  military  and 

Department  of  Defense,  Joint  Battle  Management  Command  and  Control  (JBMC2) 
Roadmap,  Draft  Version  2.0,  22  February  2005,  pp.  1-181. 
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allow  participation  of  allied  and  coalition  partners.  The  primary  challenge  to  this 
expansion  is  the  complexity  and  sensitivity  of  allowing  allied/coalition  entry  into 
the  U.S.  joint  “infosphere.”  The  GIG  should  deliver,  as  advertised,  a  “plug  and 
fight”  interoperability,  that  enables  allied  and  coalition  partners  to  connect  on  an 
as  needed  basis. 

A  coherent  and  unambiguous  common  operational  picture  requires  that 
sensors  reliably  and  clearly  identify  and  track  targets  within  the  complex 
battlespace.  Future  C4ISR  systems  will  have  to  support  a  rapid  detection  and 
precise  location  of  blue  forces  and  red  targets  for  a  shared  common  view  linked 
to  the  operational  command  decision  maker,  who  determines  the  joint  fire  of 
choice  in  an  integrated,  dynamic  fire  support  plan.^®  As  technology  integrates 
more  information  into  the  user’s  hands,  data  analysis/discrimination  will  be 
slowed  by  necessary  human  intervention.  Information  overload  will  occur.  Battle 
management  aids  will  have  to  be  developed  to  avoid  inefficiency  of  the  human  in 
the  loop  stymied  with  information  overload. 

The  reliance  on  voice  communications  permeates  current  JFS  practices, 
affecting  Fire  Support  Coordination  Agencies  (FSCAs)  and  related  elements.  As 
the  military  develops  advances  in  joint  fires  capabilities  the  reliance  on 
automated  data  may  bring  with  it  overcrowding  of  some  RF  spectrums  as  well  as 
new  requirements  for  increased  information  security  that  result  in  longer  data 
transfer  times.®° 

The  DJFSN  requires  a  real  time  operational  picture  of  targets  and 
providers.  Additionally,  blue,  gray  and  white  positions  should  be  known  with 
sufficient  accuracy  to  prevent  fratricide  and  collateral  damage.  Effective  IPB 
communicated  to  all  fire  providers  is  needed  to  set  no-fire  or  restricted  zones 
where  higher  authority  permission  is  required  to  engage  (due  to  presence  of 
SOF,  coalition  forces,  critical  infrastructure,  political  targets  etc.). 


”  US  JFCOM,  Global  Information  Grid,  15  August  2001,  p.  7. 

^  U.S.  Marine  Corps  Marine  Corps  Combat  Development  Command,  Mission  Area  Initial 
Capabilities  Document  for  Close  Air  Support,  JROCM  095-04,  14  June  2004,  p.  34. 


Ibid 


“  U.S.  Marine  Corps  Marine  Corps  Combat  Development  Command,  Mission  Area  Initial 
Capabilities  Document  for  Close  Air  Support,  JROCM  095-04,  14  June  2004,  p.  34. 


149 


7.3  AREAS  FOR  FURTHER  STUDY 


During  the  course  of  this  study,  the  Project  Team  identified  several  areas 
for  further  study. 

7.3.1  Doctrine 

Title  10  US  Code  mandated  separation  of  some  service  functions  was 
cited  as  a  reason  for  lack  of  interoperability  between  services  during  several 
stakeholder  interviews. 

An  operator’s  review  of  10USC  revealed  flaws  in  the  arguments  and 
apparent  support  for  several  of  the  team’s  recommendations.  According  to 
10USC,  the  Secretary  of  Defense  shall  take  action  to  eliminate  duplication  in  the 
Department  of  Defense®^  Additionally,  matters  of  joint  concern  shall  be 
coordinated  between  the  Army,  Air  Force,  and  Navy®^.  In  joint  operations, 
airspace  management  and  deconfliction  of  manned  aircraft,  unmanned  vehicles, 
and  ordnance  are  matters  of  joint  concern.  Coordination  between  USMC,  Army, 
and  Air  Force  for  tactics  and  equipment  used  by  landing  forces  is  also  required.®® 
With  regard  to  the  acquisition  of  systems,  the  JROC  has  a  responsibility  to  assist 
CJCS  in  assessing  joint  military  requirements.®"^  The  team  proposes  that  a 
common  command  and  control  system  should  be  a  “joint  military  requirement”. 
Title  10  also  states  the  Assistant  Secretary  of  Defense  for  C3I  “shall  have  as  his 
principal  duty  the  overall  supervision  of  command,  control,  communications,  and 
intelligence  affairs  of  the  Department  of  Defense.”  ®®  Establishing  a  Joint  PEO 
under  ASD/C3I  may  be  the  catalyst  to  develop  a  common  joint  command  and 
control  system. 


House  of  Representatives,  “10USC1 25(a)”, 
rhttp://www.access.qpo.qov/uscode/index.html1.  Nov06 
House  of  Representatives,  “10USC5062(c)”, 
rhttp://www.access.qpo.qov/uscode/index.html1.  Nov06 
House  of  Representatives,  “10USC5063(b)”, 
rhttp://www.access.qpo.qov/uscode/index.html1.  Nov06 

House  of  Representatives,  “10USC18T,  [http://www.access.qpo.qov/uscode/index.htmn. 

Nov06 

House  of  Representatives,  “10USC138(3A)”, 
rhttp://www.access.qpo.qov/uscode/index.html1.  Nov06 
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The  requirement  for  separately  developed  and  managed  systems  within 
the  component  services  appears  to  be  more  a  matter  of  “the  way  we’ve  always 
done  it”  than  public  law.  A  more  detailed  review  of  the  legal  requirements  to 
enable  more  efficient,  effective,  and  economical  operation  stated  in  10USC125 
which  we  believe  is  needed.  These  doctrine  changes  will  also  affect  the 
distribution  of  budget  between  the  services  and  how  they  organize,  train,  and 
equip  the  force. 

7.3.2  Organization  and  Leadership 

The  requirement  for  dynamic  allocation  of  assets  to  prevent  fratricide 
presents  significant  challenges  to  the  decision  makers.  The  complication  of  a 
manned  weapon  occupying  the  same  volume  of  space  as  unguided  weapons 
and  the  expected  proliferation  of  small  unmanned  aerial  vehicles  necessitates 
additional  coordination  measures.  The  various  methods  of  deconfliction  and 
development  of  a  model  to  overcome  the  organizational  challenges  of 
implementing  ‘joint  engagement  zones’  for  fires  support  requires  further  analysis. 

7.3.3  Tactics  and  Training 

The  priority  of  the  targets,  and  the  desired  effects  against  those 
targets,  determines  the  fire  support  assets  that  should  be  tasked  against  them. 
On  a  dynamic  battlefield  with  rapidly  moving  targets,  exceptionally  mobile  blue 
forces,  and  quickly  shifting  objectives,  this  aspect  of  fire  support  integration 
becomes  extremely  difficult  to  manually  accomplish.  The  final  DJFSN  system 
should  have  a  pairing  algorithm  that  can  be  tailored  to  the  commander’s  intent. 
Development  of  a  variety  of  these  pairing  algorithms  to  support  a  range  of 
operating  environments,  an  assortment  of  ROE  environments  will  be  required. 
Parallel  development  of  these  algorithms  for  testing  and  use  at  the  joint  fires 
support  cell  will  improve  the  processing  time  and  help  build  the  confidence  during 
the  transition  to  a  distributed  networked  system. 
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7.3.4  Materiel 


As  the  services  move  towards  more  restrictive  ROE  and  precision  guided 
munitions,  the  capability  to  accurately  locate  the  target  is  critical.  Otherwise 
precise  misses  result  from  PGM  on  errant  targeting  information.  An  alternative 
method  of  tasking  a  targeting  sensor  (a  remote  UAV  for  instance)  that  operates 
in  conjunction  with  a  ground  based  fires  asset  may  replace  or  enhance  the  active 
range  finder  carried  by  each  ground  unit.  BDA  assets  should  also  be  tasked  as 
part  of  the  joint  fire  support  system.  The  assumption  that  the  requester  was  in 
position  to  conduct  BDA  may  not  always  hold  true.  Consideration  to  employ 
manned  aircraft  as  weapons  delivery  and  BDA,  or  tasking  a  sensor  asset  to 
accomplish  the  assessment  should  be  part  of  the  decision  process. 

Continued  development  of  the  Global  Information  Grid  was  an  initial 
assumption  for  all  three  alternatives  considered.  The  information  data  structures, 
exchange  formats,  and  interfaces  with  existing  and  developing  systems  require 
oversight  and  evaluation.  The  common  operational  picture  assumed  to  exist  is 
predicated  on  systematic  integrated  development  of  various  command  and 
control  systems. 

7.3.5  Personnel  and  Facilities 

The  consolidation  of  the  various  service  specific  functional  entities  under 
the  centralized  system  requires  further  analysis.  Physical  and  functional  layout 
and  organization  of  this  new  functional  component  should  be  designed  and 
networked  based  on  a  human  resources  based  analysis. 

Commonality  of  training  syllabus,  collocation  of  facilities  or  cross-service 
exchange  of  instructors  should  be  evaluated. 
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APPENDIX  A. 


JFIIT  SYSTEMS  INTEROPERABILITY 


Joint  Forces  Interoperability  and  Integration  Team  Systems  Matrix  shown 
in  Table  20  identify  capabilities,  limitations,  and  interoperability  of  various 
weapon  platforms  and  the  command  and  control  equipment  across  the  Services. 


153 


APPLICATION  &  NETWORK  LEVEL 

AIRCRAFT 

s 

Q. 

Message  Standard 

Header 

Stand. 

Combat  Track  II 

SADL 

LINK-16  MIL-STD-601 6 

STANAG  5516  Tactical  Data  Exchange 

MIL-STD-3011(JRE) 

XML-CoT 

AFAPD 

MTS  TIDPS/  SDN-C21 03-442  17  OCT  94 

VMF  TIDP-FTE  R2  (VMF) 

VMF  TIDP-FTE  R6  (VMF  +ACAS) 

VMF  TIDP-FTE  R6  w/imagery  message 

VMF  MIL-STD-601 7 

VMF  MIL-STD-601 7  w/lmagery  Message 

VMF  MIL-STD-601 7A 

MIL-STD-2045-47001B 

MIL-STD-2045-47001C 

MIL-STD-2045-47001D 

AH-1W 

AH-1Z 

P^ 

P^ 

AH-64D 

P^ 

A-10 

P^ 

P^ 

A/V-8B 

X 

P^ 

P^ 

F/A-18  A+/C/D, 

F/A-18  E/F  [22-24] 
F/A-18  E/F  [25&up] 

o' 

X 

X 

F/A-18  A+/C/D, 

o' 

X 

X 

X 

F/A-18  E/F  [25&up] 

o' 

X 

X 

X 

F/A-18  A+/C/D, 

F/A-18  E/F  [22-24] 
F/A-18  E/F  [25&up] 

0^ 

P^ 

P^ 

F/A-18  E/F  [25&up] 

0^ 

P^ 

P^ 

F-16C,  Block  25/30/32 

X 

F-16CG,  Block  40/42 

p^ 

X 

F-16CJ,  Block  50/52 

X 

X 

AC-130H 

X 

X 

AC-130U 

X 

X 

F-15E 

X 

B-1 

X 

p^ 

B-2 

X 

X 

B-52 

X 

p^ 

P^ 

P^ 

P^ 

F/A-22 

p^ 

F-35 

p^ 

P^ 

P^ 

JTAC  GROUND 
SYSTEMS 

TLDHS 

X 

X 

X 

X 

P^ 

P^ 

X 

X 

BAO  w/Gateway 

p^ 

X 

TACP-M  wo/Raider 

X 

X 

X 

X 

P^ 

P^ 

X 

X 

TACP-M  w/  Raider 

P^ 

p^ 

P^ 

X 

X 

X 

X 

P^ 

P^ 

X 

X 

Table  20 
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PHYSICAL/SIGNAL  LEVEL 

AIRCRAFT 

Radio 

Physical  &  Signal 
Standards 

JTIDS/  MIDS  Terminal  (R/T) 

CM 

00 

o 

O 

< 

ARC-210  R/T  1851  (Warrior) 

ARC-210  R/T  1 851 B  (5th  Gen) 

AMF  JTRS 

AN/PRC-1 17F(or  equivalent) 

LINK-16  MIL-STD-6016 

STANAG  4175  Tchnical  Characteristics  of  tf 

MIL-STD-3011(JRE) 

UHF  Amplitude  Modulation 

AH-1W 

AH-1Z 

P^ 

AH-64D 

A-10 

A/V-8B 

P^ 

X 

F/A-18  A+/C/D, 

F/A-18  E/F  [22-24] 
F/A-18  E/F  [25&up] 

0^ 

X 

0^ 

X 

F/A-18  A+/C/D, 

0^ 

X 

0^ 

X 

F/A-18  E/F  [25&up] 

0^ 

X 

0^ 

X 

F/A-18  A+/C/D, 

F/A-18  E/F  [22-24] 
F/A-18  E/F  [25&up] 

0^ 

p^ 

0^ 

P^ 

F/A-18  E/F  [25&up] 

0^ 

P^ 

0^ 

P^ 

F-16C,  Block  25/30/32 

F-16CG,  Block  40/42 

P^ 

X 

F-16CJ,  Block  50/52 

X 

AC-130H 

AC-130U 

F-15E 

X 

X 

B-1 

P^ 

P^ 

B-2 

X 

X 

X 

B-52 

P^ 

? 

p^ 

p'  1 

F/A-22 

P^ 

p^ 

F-35 

p^ 

p'  1 

JTAC  GROUND 
SYSTEMS 

TLDHS 

X 

X 

BAO  w/Gateway 

X 

p^ 

X 

TACP-M  wo/Raider 

X 

X 

X 

TACP-M  w/  Raider  X  X 

X 

X 

X 

0^=lnstalled  but  not  planned  to  support  JTAC  to  Aircraft  CAS 

Prop'^=  Proprietary  Specification 


X  =  Existing 

P^=Program/Service  Planned 
P^=lnstalled,  ICD  w/  Strikelink  PICombat  Track  II  Protocol 
P^=Program  /Service  Planned  fo 
Chuck  Cratsley  757-203-4492 
USJFCOM  J89  r 


SADL  Protocol 
JTIDS/Link-16  Related  Stds 


BAO  Kit  Protocol  Stack 
Traditional  Modem-Based  Protocols 
Primary  System  Configuration  Item 


Table  20:  JFIIT’s  Interoperability  and  Capability  Matrix  (cont.) 
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APPENDIX  B.  JOINT  FIRE  SUPPORT  REQUEST  DATA  FORMATS 

The  Project  Team  asserted  that  the  call-for-fire  data  requirements  are 
constant  across  the  services.  The  team  has  reviewed  the  primary  methods  to 
complete  a  call  for  fire  for  various  types  of  providers  to  ensure  the  data  contained 
in  these  different  requests  is  essentially  static. 

For  artillery  calls  for  fire,  a  normal  call  for  fire  consists  of  six  elements: 
Observer  identification,  Warning  Order  (which  includes  the  type  of  mission,  the 
size  of  the  element  to  fire  for  effect,  and  the  method  of  target  location),  Target 
Location,  Target  Description,  Method  of  engagement,  and  Method  of  fire  and 
control.  These  elements  are  transmitted  by  voice  communication  in  three  parts, 
with  each  part  being  read  back  to  the  originator  to  ensure  accurate  transmission. 

If  an  artillery  call  for  fire  is  completed  within  AFATDS,  the  basic  data  entry 
screen  requires  the  input  of  the  observer  identification,  unit  composition, 
ammunition  type  requested,  target  location,  target  type  guidance,  and  map 
version  used  in  the  handheld  terminal.  By  design,  these  data  elements 
correspond  directly  to  the  items  required  for  a  verbal  call  for  fire. 

Requests  for  CAS  are  completed  via  a  DD  Form  1972  Air  Strike  Request 
and  a  “9-line”  engagement  message.  (Due  to  widely  varying  equipment 
baselines  in  the  aircraft  fleet,  there  is  no  parallel  to  an  AFATDS-like  system.) 
While  there  at  least  21  different  versions  of  the  9-line,  the  data  contained  in  the 
different  versions  are  basically  static  and  compare  very  closely  with  the  data 
elements  needed  for  artillery  requests.  From  Table  21,  the  core  data  elements 
(contained  in  >50%  of  the  formats)  are  evident 
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Call  for  Fire  Formats 

JFIRE  Variables 

1 

2 

3 

4 

5 

6 

7 

8 

E 

ED 

EQ 

EE 

ED 

EE 

EE 

EE 

m 

E 

Q] 

B1 

Total 

Target  location  /  coordinates 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

D 

D 

16 

Callsign:  Observer  ID  /  aircraft  /  JTAC 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

14 

Target  description 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

13 

Method  of  engagement  /  type  of  ordnance 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

11 

Heading  to  target  /  direction 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

10 

Clearance  /  method  or  type  of  control 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

10 

Friendly  position 

X 

X 

X 

X 

X 

X 

X 

7 

Distance  to  target 

D 

D 

X 

X 

X 

X 

6 

Authentication 

X 

X 

X 

D 

X 

X 

6 

Abort  code 

D 

X 

X 

X 

X 

X 

6 

Time-on-target  /  Time-to-target 

X 

X 

X 

X 

X 

5 

Number  and  type  of  aircraft 

X 

X 

X 

X 

X 

5 

Mission  Number 

D 

X 

X 

X 

X 

5 

Mark  type 

X 

X 

X 

X 

X 

5 

Target  Elevation 

X 

X 

X 

X 

X 

5 

Weather  /  hazards 

X 

X 

X 

X 

4 

Threats  in  the  target  area 

X 

X 

X 

X 

4 

Remarks 

X 

X 

X 

X 

Position  of  aircraft 

X 

X 

X 

X 

4 

Play  time 

X 

X 

X 

X 

4 

Initial  Point 

X 

X 

X 

X 

4 

Egress  direction  /  instructions 

X 

X 

X 

3 

Restrictions 

X 

X 

Artillery  (max  ordnanace  /  gun-to-target  line) 

D 

D 

Target  area  description 

X 

1 

Intelligence  /  situation  update 

X 

1 

Ground  commanders  initials 

0 

Table  21 :  Close  Air  Support  Call  for  Fire  Format  (From®®) 


As  a  result  of  this  analysis,  the  team  felt  confident  in  assuming  the  data 
required  to  engage  a  target  was  not  significantly  different  based  on  the  mode  of 
engagement. 

Simplicity  under  combat  conditions  is  a  characteristic  of  the  above 
formats.  However,  these  simple  data  structures  aren’t  sufficient  to  describe  the 
battlespace  for  C2  Automated  Information  Systems. 

The  Joint  Consultation  Command  and  Control  Information  Exchange  Data 
Model  (JC3IEDM)  was  developed  by  the  Multilateral  Interoperability  Program 
(MIP)  at  NAVSEA,  Dahlgren,  VA.  The  JC3IEDM  is  essentially  a  pre-negotiated 
data  structure  to  share  Command,  Control,  and  Communications  (C3)  data 
between  28  participating  nations.  This  robust  data  structure  of  over  2000 
elements  would  permit  a  very  high  degree  of  data  interoperability  between 
participating  nations.  If  fully  implemented,  the  JC3IEDM  would  require  extensive 
changes  to  or  replacement  of  existing  equipment  and  software.  JC3IEDM 
implements  an  extensible  Mark-up  Language  (XML)  format  and  would  require 
much  more  bandwidth  than  current  ASCII  text-based  equipment.  While  the 


“  D.  C.  Clayton,  Air  Combat  Command  USAF  Weapons  Review,  Winter  2005,  “Close  Air 
Support  Briefings  for  the  Future:  Alterations  to  the  9-line”,  p.  40 
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JC3IEDM  construct  is  on  the  interoperability  path  of  many  of  the  major  C2 
systems,  the  hardware  at  the  edges,  such  as  the  data  links  onboard  aircraft  or  in 
handheld  data  terminals,  will  probably  not  capitalize  on  it. 
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APPENDIX  C. 


CURRENT  JFS  COORDINATION  AND  DECISION¬ 
MAKING  COMPLEXITY 


Figures  53  through  55  are  additional  examples  of  the  challenges  in 
requesting  fie  support  outside  of  traditional  service  coordination  channels  in  the 
current  system. 


ARPOR/ JFC  i 


Figure  53:  Army  Soldier  Requesting  Fire  Support 
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Figure  54:  Navy  Sailor  Requesting  Fire  Support 
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Figure  55:  TLAM  Request  Processing 
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APPENDIX  D. 


INPUT-OUTPUT  MODELING  PROCESS 


The  first  consideration  when  attempting  to  characterize  any  system  with 
an  Input-Output  (1-0)  Model  is  to  determine  the  intended  outputs.  The  systems 
engineering  process  inputs  combine  the  customer’s  requirements  and  the  project 
constraints.  The  controllable  inputs  determine  what  is  needed  to  start  the 
process  in  order  for  the  outputs  to  be  achieved.  The  controllable  inputs  must  be 
able  to  shorten  the  fire  support  tasking  cycle  by  having  the  capability  to  task  a 
request  expeditiously.  Controllable  inputs  apply  to  areas  that  can  be  controlled  by 
the  human  interface  with  the  system.  These  include,  but  are  not  limited  to: 
training,  C2,  and  the  type,  number,  placement,  and  grouping  of  targeting  sensors 
for  a  specific  operation,  in  addition  to  tactics  and  logistics. 

Uncontrollable  inputs  are  those  mostly  environmental  characteristics  that 
influence  the  performance  of  the  system.  They  are  inevitable  factors  such  as 
geography,  climate,  and  topography.  The  uncontrollable  inputs  of  our  system 
often  detract  from  the  intended  outputs.  The  proposed  fire  support  system 
solution  must  be  able  to  operate  a  range  of  dynamic  environments  from  force-on- 
force,  to  rear  area  support  and  urban  combat. 

By-products  of  the  systems  process  are  unintentional  or  incidental  outputs 
that  have  a  positive  or  negative  effect  on  achieving  the  overall  goal  of  the 
system.  Some  of  the  by-products  that  have  been  identified  by  the  Project  Team 
include  such  things  as  sensor  failure  and  enemy  responses.  The  1-0  Model 
helps  provide  information  on  the  performance  characteristics  of  the  system  and 
relates  to  how  well  the  system  will  work  in  its  intended  environment.  Once  the 
outputs  have  been  generated  and  bounded,  the  analysts  can  begin  to  make  a 
determination  of  the  effective  need  of  the  client  and  goals  that  satisfy  this  need. 
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APPENDIX  E.  FUNCTIONAL  FLOW  ANALYSIS 

The  functional  flow  of  items  through  the  proposed  system  was  deliberately 
decomposed  into  smaller  steps  as  outlined  in  Figures  56  through  61. 


Figure  56:  Proposed  System  Decomposition 
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Second-level  Functions 


1.0  Send  JF  Request 


Figure  57:  Send  JF  Request  Sub-functions 


Second-level  Functions 


2.0  Process  JF  Request 


Figure  58:  Process  JF  Request  Sub-functions 
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Second-level  Functions 


3.0  Send  JF  Tasking  to  Provider 


Figure  59:  Send  JF  Tasking  Sub-functions 


Second-level  Functions 


4.0  Provider  Accepts/Reciamas  Tasking 


Figure  60:  Provider  Tasking  Sub-functions 
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Third-level  Functions 


2.5  User- Provider  Matching  of  Requests 


Figure  61 :  Request-Provider  Pairing  Sub-functions 
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APPENDIX  F. 


STAKEHOLDER  ANALYSIS  AND  SUPPORTING  DATA 


Stakeholder  analysis  enables  the  designer  to  identify  the  system's 
effective  need  as  well  as  critical  assumptions  and  constraints  of  the  defined 
problem.  These  may  come  from  a  variety  of  sources  and  might  include 
assumptions  ranging  from  strategic  to  tactical.  While  time  and  money  are  the 
most  typical  constraints,  there  are  also  physical,  legal,  environmental,  social  and 
technological  constraints  that  may  be  relevant  and  must  be  considered. 

The  Project  Team  began  identifying  stakeholders  who  would  determine 
the  system  requirements,  scope  and  bound  the  problem,  and  be  involved  in  the 
entire  process  of  definition,  development,  and  deployment  of  the  solution. 
Stakeholder  analysis  has  several  sub  steps  that  include:  (1)  identifying 
stakeholders;  (2)  conducting  interviews  with  stakeholders;  (3)  identifying 
stakeholders’  needs,  wants,  and  desires  for  the  proposed  system; 
(4)  consolidating  information. 

Stakeholders  can  be  separated  into  five  major  categories.  Each  category 
identifies  a  unique  function  and  perspective  that  the  specific  stakeholders  in  that 
category  provided  the  team.  These  five  categories  are: 

1 .  Decision  Makers 

2.  Clients 

3.  Sponsors 

4.  Users 

5.  Analysts 

For  the  proposed  Joint  Fires  in  2020  system,  the  following  stakeholders 
were  identified  with  respect  to  these  five  categories: 

Decision  makers  have  the  authority  to  make  impacting  and  final  project 
decisions  when  multiple  design  choices  are  available.  Because  the  purpose  of 
the  proposed  future  systems  includes  the  weapon  effectiveness  of  Joint  military 
assets,  the  practical  primary  decision  maker  is:  the  Joint  Fires  Integration  and 
Interoperability  Team  (JFIIT). 
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Clients  are  agencies  or  groups  of  people  that  will  have  substantial  input 
as  to  the  development  of  the  solution  set.  They  include  Combatant  Commanders 
(COCOMs)  and  each  of  the  armed  services. 

Sponsors  are  offices  or  groups  of  people  that  provide  financial  support, 
which  may  include  technical  support  or  support  in  the  form  of  special  studies  or 
specialized  information,  and  include  the  Naval  Postgraduate  School  (NPS). 

Users  are  agencies  or  groups  of  people  that  will  actually  use  the  system 
that  is  developed.  Practical  users  include  Operators  (all  U.S.  military)  and 
defense  contractors. 

Finally,  the  project  team  analysts  will  evaluate  the  effective  need  and 
assist  in  determining  the  projected  performance  of  various  system  alternatives. 
These  include  the  SEA-10  Joint  Fires  Project  Team  and  NPS  faculty,  staff 
and  students. 

Based  on  efforts  to  identify  the  stakeholders,  the  team  traveled  to  visit  and 
discuss  JFS  with  the  organizations  described  below.  The  following  excerpts  are 
trip  report  e-mails  sent  by  members  of  the  team  immediately  after  each 
stakeholder  visit.  Each  trip  report  describes  the  significant  events  and 
knowledge  gained  on  each  trip. 


Stakeholders: 

Location: 

Audience: 

Author: 


US  Marine  Corps  AFATDS  Training  Center 
AFATDS  Software  Development  Project  Manager 
Fort  Sill,  Oklahoma,  May  2006 
Joint  Fire  Support  in  2020  Team  &  Advisors 
MaJ  Tyler  Gabriel 


Overall,  the  short  visit  to  Fort  Sill,  OK  was  incredibly  helpful 
in  all  respects  and  I  honestly  believe  that  we  have  saved  weeks  or 
months  of  project  effort  by  making  this  short  trip.  The  amount  of 
information  we  received  was  enormous  and  the  insight  into 
customer  needs  and  stakeholder  inputs  we  gained  during  our 
tabletop  discussions  with  the  Marines  there  gave  us  a  whole  new 
perspective  on  our  Joint  Fires  project  concept. 

On  Thursday  morning,  we  met  with  the  USMC  contingent  on 
Fort  Sill  responsible  for  training  Marines  on  the  AFATDS  system. 
Officers  and  Senior  Marine  NCOs  spent  about  V/2  hours  just 
describing  and  demonstrating  AFATDS,  EMT  (Effects  Management 
Tool),  PSSSOF  (Precision  Strike  System,  SOF),  C2PC,  JTCW,  and 
the  MRT/TLDHS  (AKA  Strikelink),  a  new  piece  of 


170 


hardware/software  that  has  recently  joined  the  AFATDS  system  of 
systems.  After  a  thorough  review  of  how  a  Marine  (or  Army  Gl,  or 
possible  Riverine  sailor)  actually  makes  a  call  for  fire  using  the 
AFATDS  family  of  equipment,  and  how  that  request  gets  sent, 
processed,  approved,  prioritized,  allocated,  tasked,  serviced,  and 
assessed,  they  spent  the  next  2  hours  answering  our  questions 
about  stakeholder  needs  and  helping  us  to  understand  where  the 
current  systems  are  not  meeting  those  needs.  All  of  these  Marines 
have  recently  returned  from  OIF  and  had  actual  experience 
interfacing  the  AFATDS  and  MFCS  systems  aboard  a  ship  in  the 
Persian  Gulf.  We  also  talked  briefly  about  one  recent  application  of 
the  AFATDS  technology,  a  rapid  anti-mortar  counter-fire  capability, 
which  has  direct  tie-in  to  the  efficiency/timeliness  of  the  technology 
in  place  and  the  advantages  of  the  rapid  responsiveness.  This  was 
a  very  productive  meeting,  and  we  learned  a  lot  about  the  current 
system  architecture  and  interaction,  as  well  as  programs  that  are  in 
development  and/or  in  limited  fielding. 

Thursday  afternoon,  we  met  with  the  program  requirements 
manager  for  the  AFATDS  software  for  4  hours.  After  seeing  the 
operation  of  the  current  equipment  with  the  USMC,  we  were  able  to 
pepper  him  with  informed  questions  about  the  Joint  Fires  process 
and  the  requirements  process  that  generated,  and  continues  to 
refine,  the  AFATDS  system.  Of  note,  the  AFATDS  system,  as  a 
‘System  of  Record’  designation,  is  by  mandate  projected  to  be  THE 
primary  mechanism  for  fire  support  in  both  the  USA  and  USMC 
until  around  2016.  The  next  block  software  cycle,  due  out  later  this 
year,  will  move  to  a  Windows  OS  (instead  of  the  Unix  OS  it  is  on 
now),  will  include  XML  capability  in  addition  to  its  current 
VMF/USMTF  (Variable  Message  Format/US  Message  Text  Format) 
messaging  capability,  and  it  will  also  be  able  to  provide  a  specific 
deconfliction  ‘tunnel’  for  planned  shells/rockets/missiles  to  aid  in 
better  deconfliction  with  airborne  aircraft  (and  civil  air  as  in  the  case 
of  Iraq).  The  first  version  of  AFATDS  was  fielded  in  1996,  so  it  has 
been  in  refinement  and  development  for  10  years,  making  it  an 
established  and  refined  program  that  has  incorporated  10  years  of 
customer  inputs  to  get  to  the  functionality  that  it  has  today.  One 
important  aspect  of  AFATDS  that  we  learned  from  both  the  Marines 
and  the  software  program  manager  is  the  2  different  functions, 
tactical  and  technical,  in  the  same  software/hardware  package. 
The  technical  function  is  the  side  of  the  software  that  computes 
exactly  where  to  point  the  tubes/MRLS  (essentially  a  weapon 
system  component),  and  the  tactical  function  is  the  side  of  the 
software  that  prioritizes,  allocates,  and  tasks  based  on 
commander’s  guidance.  An  important  part  of  the  AFATDS  software 
that  we  discussed  with  the  software  program  manager  in  detail  was 
the  compatibility  issues  with  other  existing  systems.  AFATDS  is 
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currently  able  to  communicate  directly  to  over  60  other  systems 
using  its  VMF/USMTF  message  format.  Several  other  systems, 
including  JADOCS  (Joint  Advanced  Deep  Operations  Coordinated 
System... simply  renamed  from  ADOCS  to  generate  funding)  which 
should  soon  be  supplanted  by  WEEMC  (Web-Enabled  Execution 
Management  Capability),  and  the  upcoming  Net-Enabled 
Command  Capability  (NECC)  were  discussed.  We  had  a  great 
discussion  of  the  shortcomings  of  AFATDS  and  all  of  the  other  Joint 
Fires-related  software  and  the  TTP/doctrinal  disconnects. 
Interestingly,  it  appears  the  AFATDS  systems  wasn’t  originally 
developed  using  a  systems  engineering  process.  Only  after  10 
years  of  customer  feedback  have  they  managed  to  provide  a 
system  that  meets  the  customer’s  (ground  unit)  effective 
needs...  mostly. 

“Take  Aways’’-  The  AFATDS  system  seems  to  be  already  doing 
exactly  what  the  Army  and  Marines  want  it  to  do  for  organic  indirect 
fires  (mortar,  arty,  rockets,  etc),  but  the  Joint  Fire  Support  request 
system  starts  breaking  apart  once  it  tries  to  leave  the  ground 
commander’s  purview  (i.e.  CAS,  Naval  Fires).  This  is  where  all  of 
the  advantages  of  this  digital  request  format  are  lost  by  human-in- 
the-loop  hurdles,  which  means  that  there  has  been  little  or  no 
quantifiable  improvement  in  CAS/NSF  during  the  decade  between 
Desert  Storm  and  OIF/now.  This  is  where  Shawn  and  I  think  we 
should  focus  our  analysis... there  is  an  effective  need  here  for 
customers  across  all  of  the  services. 


Stakeholder: 

Location: 

Audience: 

Author: 


Joint  Fires  Integration  and  Interoperability  Team 
Egiin  AFB,  Fiorida,  June  2006 
Joint  Fire  Support  in  2020  Team  &  Advisors 
LCDR  Matt  Bartei 


The  trip  to  JFIIT  went  well. 

As  for  the  briefs  and  the  briefers:  overall  impression  is  that 
these  guys  are  the  single  joint  source.  Nobody  else  is  working  on  a 
joint  picture  that  they  could  think  of.  There  are  a  slew  of  civilians 
and  contractors  on  staff,  and  only  a  few  military  (the  CO,  LCOL 
Ringler,  and  a  few  enlisted  folks).  The  contractors  are  almost 
exclusively  folks  involved  in  joint  fires  (Marine  FACs,  former  A-10 
driver.  Naval  Aviators,  and  Intel).  They  (JFIIT)  are  the  result  of 
combining  the  CID  (Combat  Identification,  think  BlueForce  Tracker, 
etc),  and  the  Joint  Fires  folks  commissioned  by  JFCOM.  About  140 
total  personnel.  They've  done  some  research,  with  a  lot  of  it  at  the 
National  Training  Center.  We  are  invited  to  the  next  NTC  event, 
August  12-15.  The  data  they've  collected,  however,  doesn't  seem 
very  useful  from  a  modeling  perspective... they  monitor 
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communications  and  layer  each  units  SA  to  a  ground  truth  (reality) 
to  see  how  well  the  picture  is  being  relayed  up  and  down  the  chain. 
Here’s  a  rundown  of  the  briefs: 

Intro  from  LCOL  Ringler:  Welcomed  us  and  offered  all  his 
resources... really  looking  to  help  us  in  any  way  he  can.  Changing 
command  in  a  month  or  two,  but  guaranteed  his  replacement  would 
have  the  same  attitude.  Asked  about  other  organizations,  he  said: 
CNA  (Center  for  Naval  Analysis).. .should  have  lots  of  data/info, 
JFCOM  (POC  pending),  JAGO  offices  (Joint  Air  Ground 
Operations). ..never  heard  of  them,  and  look  at  the  Marine  Corps 
lessons  learned  on  Joint  Fires  (I'm  looking  into  this. ..it  should  be 
unclas).  As  far  as  data  for  the  models,  they  have  anecdotal  info 
(interviews  and  surveys,  with  a  big  one  finishing  next  month),  but 
not  much  we  can  directly  plug  into  our  model,  and  no  model  of  their 
own  to  simulate  joint  fires... their  "model"  is  collecting  data  at  live  fire 
and  exercise  events  to  give  performance  feedback.  Steve  Mechum 
(Intel  guy  who  coordinated  for  us)  said  he'd  look  at  finding  what 
we're  looking  for. 

Ron  Spock  -  Laser  Rangefinder  Quicklook  method:  At  first  I 
thought  this  brief  wouldn’t  be  useful,  but  it  turned  out  to  be 
insightful.  There  are  5  laser  rangefinders  currently  in  use. ..they 
didn't  recognize  my  weak  attempt  at  describing  the  Strikelink 
LRF/tablet  system.  The  five  are:  LLDR  (Northrop  Grumman 
product  with  Thermal  and  Video),  the  Mk  7  (most  widely  used),  the 
Viper  2  (no  longer  manufactured),  the  Vector  21  (replacement  unit 
for  Viper  2),  and  the  LH-40/41  (limited  manufacture).  All  of  these 
produced  a  mean  error  of  6-175  meters  due  primarily  to  the 
magnetic  compass.  JFIIT  devised  a  method  to  improve  to  5-40 
meters  mean  error  using  the  "Quicklook"  method  (using  a  known 
fixed  point  to  determine  declination  and  improve  the  coordinates 
passed).  When  I  asked  about  digitized/automated  systems,  they 
said  "bad  data  fast  is  still  bad  data".  We  eventually  got  around  to 
the  point  that  nearly  every  transmission  of  coordinate  data  is 
transmitted  by  voice.  This  brief  also  raised  the  point  of  joint  fires 
also  being  joint  ISR  (in  other  words  joint  target  location... USAF  unit 
finds  target  for  Army  unit  to  be  engaged  by  Army  MLRS).  Their 
biggest  emphasis  for  future  trends  was  CDA/CDE  (collateral 
damage  analysis/estimate);  smaller  and  smaller  warheads  to  attack 
a  target  due  to  political  correctness. 

Mike  Higgins/Tim  Finn  (Tim  Finn  wrote  quite  a  bit  of  the  Joint 
Fires  pubs)  -  JBMC2  (they  used  this  acronym  quite  a  bit  at  JFIIT). 
Like  almost  all  the  briefers,  the  emphasis  is  on  JCAS.. .little 
integration  of  artillery/indirect  fires,  and  no  integration  of  NSFS. 
They  had  only  a  limited  knowledge  of  current  and  planned  Naval 
weapons  like  ERGM  and  the  Rail  Gun.  This  brief  brought  forward 
one  of  the  biggest  lessons  learned  (from  my  perspective):  a  major 
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part  of  our  analysis  should  go  into  the  politics  of  the  current 
problem  (the  major  reason  the  military  is  not  "joint")... and  that  is 
Title  10.  I'll  be  honest  and  say  I  don't  know  a  whole  lot  about  it,  but 
every  brief  mentioned  that  service  parochialism  and  Title  10  are  the 
major  roadblocks  to  truly  joint  fires.  It  doesn't  allow  for  the 
interoperability  necessary  for  close  coordination.  It  took  them  a 
year  to  do  the  analysis  of  JCAS  problems,  but  the  data  is 
summarized  in  two  excel  spreadsheets  that  have  more  data  than 
we  could  process  in  the  time  there... all  the  holes  between  aircraft 
and  systems  (who  can't  talk  to  whom,  etc).  Great  data.  Also 
mentioned  talking  to  the  Military  Operational  Research  Society 
(MORS)  for  more  data.  They  also  spoke  of  a  CJTFEX  (Combined 
Joint  Task  Force  Exercise)  04-02.  They  spent  millions  of  dollars 
putting  SA-6's  and  Scuds  in  the  North  Carolina  countryside  for 
"Joint  Fires". ..the  targets  were  found  by  national  assets,  but  the 
information  never  made  it  to  the  trigger  pullers  (they  mostly  faulted 
the  Navy,  who  was  in  overall  command,  for  not  processing  and 
relaying  the  info).  Again,  a  great  ISR  tie-in.  They  recommended 
analyzing  Joint  Vision  2010  and  2020  for  the  discrepancy  between 
what's  been  mandated  and  what's  possible,  especially  in  the  realm 
of  the  F-35  JSF  (hard  joint  requirements  that  conflict  with  service 
requirements).  Tim  also  took  the  time  to  explain  exactly  how  you 
go  from  user  to  provider  (in  a  generic  sense):  Ideally  you  have  a 
TACP  (Tactical  Air  Control  Party)  who  is  a  JTAC  (Joint  Terminal  Air 
Controller).. .could  be  officer  (FAC  qualified)  or  could  be  enlisted. 
They  submit  a  voice  request  to  the  USAF  Air  Request  Net, 
proposed  to  become  the  Joint  Request  Net.  This  request  is  then 
sometimes  transferred  to  a  form  DD  1972  to  go  through  Army 
channels  for  indirect  fires.  The  coordination  happens  at  the  DASC 
(Direct  Air  Support  Center,  USMC)  or  ASOC  (Air  Support 
Operations  Center,  USA).  The  question  of  allocation  or 
prioritization  seemed  very  fuzzy,  and  I  wasn't  convinced  of  a 
standard  approach  aside  from  commander's  prerogative.  The  joint 
coordination  seems  missing  entirely  once  you  leave  the  CAS 
arena... they  mentioned  AFATDS  use  by  both  the  Army  and  the 
Marines. 

Scot  Chiasson  (A-10  Driver)  -  Joint  Fires  Model.  The  Joint 
Fires  "Model"  is  actually  a  UML  representation  of  the  kill  chain.  He 
presented  the  F2T2EA  kill  chain,  and  the  presentation  does  an 
outstanding  job  of  dissecting  it.  He  also  showed  us  another  kill 
chain,  D3A  (Decide,  Detect,  Deliver  and  Assess).  I  obviously  like 
the  way  we're  going  better  (F2T2EA).  His  presentation  explains 
target  selection  within  this  kill  chain,  including  the  allocation  of 
assets  for  TST  and  on-call  fires.  Good  explanation,  but  not  a  model 
in  the  sense  of  what  we're  going  to  need  to  do.  Brought  up  the 
urgent  need  for  MOE's  and  MOP's,  and  he  referred  me  to  "Annex 
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A". ..lots  of  time/Pk/etc  metrics  that'll  be  on  SharePoint  shortly. 
When  pressed  for  an  allocation  scheme,  he  referenced  AFATDS 
and  the  way  it  handles  calls  for  fire.  He  said  there  was  an 
automated  process  for  allocation  that  the  commander  can  tailor 
with  intent... maybe  Tyler  and  Shawn  know  more  on  this. 

On  the  technology  side  of  things,  they  mentioned  Link  16  is 
not  currently  compatible  for  CAS  (you  have  to  enter  an  air  target  at 
0  altitude  to  point  out  a  ground  target).  A  neat  system  they 
mentioned  was  Rover  3,  a  system  that  allows  the  JTAC  to  see 
exactly  where  the  aircraft's  sensors  are  pointing  (a  video  display  of 
what  the  pilot  is  looking  at  in  his  FLIR/etc). 

Col  Andy  Balding  (USMC,  Ret)  gave  a  brief  on  training  and 
the  plan  for  future  JTAC... doesn't  look  good.  The  capacity  is  barely 
there  to  maintain  the  requirements  as  it  is,  and  the  plan  is  to  double 
output.  Major  roadblock  is  aircraft  sorties  for  live  fire  training. 
Again  mentioned  Title  10  roadblocks  to  integration.  Extensive  brief 
on  the  T  part  of  DOTMLPF. 

Overall  the  trip  was  beneficial  and  provided  good  insight  to 
the  communications  and  breakdown  of  Joint  Fires  between  the 
services. 
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Various  Air  Force,  Army,  Navy,  and  Marine  Corps 
personnel  and  Professors 

Naval  Post  Graduate  School  Monterey,  California, 
July  2006. 

Joint  Fire  Support  in  2020  Advisors  &  Team 
LT  Spencer  Nordgran 


The  Joint  Fire  Support  in  2020  held  its  interim  Project 
review  in  July,  2006.  This  meeting  was  held  to  get  expert  faculty 
and  student  input  from  experienced  personnel  in  the  area  of  Joint 
Fires,  Fires,  and  Systems  Engineering.  Numerous  personnel  from 
the  Army,  Marine  Corps,  and  Navy,  as  well  as  several  professors 
and  retired  flag  rank  military  personnel  were  in  attendance.  The 
meeting  was  very  successful  and  allowed  the  opportunity  to  meet 
subject  matter  experts  in  several  joint  fire  areas  to  assist  in  the 
scoping  and  bounding  of  the  project.  The  following  questions  and 
comments  were  addressed: 


1 .  Maj  Che’  Bolden 

-Are  you  using  kinetic  or  non-kinetic  fires? 
-Organic/non-organic? 

-Request  is  it  from  a  human  or  will  you  include  UAV’s  etc. 
-Who’s  doing  tracking? 

-electronic 

-human 
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-May  want  to  start  at  lowest  level.  USMC  uses  battalion 

level. 

2.  MAJ  Tony  Knight 

-Guy  on  the  ground  already  knows  what  he  wants. 

-Multi  Asset  (possible  thesis  topic). 

-How  are  you  going  to  positively  identify  a  1500  yard  target 
(UAC,  UCAV,  etc.)? 

3.  MAJ  Tom  Stoner 

-How  are  you  going  to  encompass  TST  stuff? 

-Caution  separating  request  from  process. 

-What  will  JTF’s  role  be? 

4.  Admiral  Mike  Jones 

-What  type  of  C4I  is  being  proposed? 

5.  Tom  Pugsley 

-Is  someone  waving  the  flag  and  making  the  big  push  for 
what  the  priorities  should  be? 

6.  MAJ  Ty  Neuman 

-2015  and  on  doesn’t  matter  the  ordnance/platform,  all 
electronic,  link/architecture  should  be  able  to  drop  on  target  and  be 
adaptable  for  new  technology. 

7.  MAJ  Mike  Shewfelt 

-Direct/indirect  support,  everything  initially  falls  into  general 
support  or  general  category  then  it  will  be  prioritized,  ordered,  etc. 
(intended  plan  for  the  2015  time  frame). 

8.  Phil  Acquaro 

-Collateral  damage  estimates,  are  you  looking  at  it? 

-JCA,  what  is  the  effect,  do  you  use  regional,  multi-regional, 

etc? 

9.  Prof.  Langford 

-Problem,  increased  vulnerability  to  mission  completeness, 
quicker  response  &  effective  use  of  weapons? 

All  of  these  personnel  were  experienced  in  Joint  Fires  or 
Systems  Engineering.  A  lecture  was  given  on  the  scope  and 
current  direction  (at  the  time)  of  the  Joint  Fire  Support  in  2020. 
Although  some  of  the  questions  were  outside  the  bounds  of  the 
Joint  Fire  support  in  2020  project,  the  input  was  vital  and  the 
information  was  very  helpful  in  considering  issues  in  these  specific 
areas. 
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National  Fire  Control  Symposium 
Tucson,  Arizona,  Juiy  2006 
Joint  Fire  Support  in  2020  Team  &  Advisors 
Maj  Brian  Peters 
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Overall:  We  all  should  have  gone  to  this  symposium.  Not  only 
would  we  all  be  on  the  same  page  for  what  we  learned,  we  could 
have  worked  with  a  few  more  of  the  technical  people  at  the 
conference  at  a  deeper  level.  Aspects  of  our  project  are  being 
completed  by  many  other  organizations  within  the  services.  All  of 
them  really  seem  “to  get”  the  issue  at  hand,  even  if  there  doesn’t 
seem  to  be  any  overarching  leadership  to  focus  the  effort. 

Leo  and  I  were  puzzled  at  the  lack  of  military  representation 
at  the  symposium.  Besides  the  two  of  us,  there  were  maybe  5 
other  military  in  a  crowd  of  200+  contractors,  government  civilians, 
etc.  If  there  were  any  government  “decision  makers”  in  the  crowd 
(military  Program  Managers,  PEOs,  HQ  staffers),  they  were 
keeping  a  low  profile. 

This  forum  yielded  very  valuable  information  and  contacts  for 
our  project.  We’ll  break  down  some  of  the  key  contacts/projects  so 
you  can  all  get  an  idea  where  we  can  leverage  their  efforts  to  fill 
some  of  our  gaps.  While  we  signed  up  to  get  a  copy  of  all  the 
briefings/papers  (in  a  few  weeks),  we’ll  have  to  follow  up  with  most 
of  these  contacts  individually  if  we  want  information  sooner... 

Service  Perspectives 

The  sessions  started  with  overviews  from  the  Army,  Navy, 
and  Air  Force.  Interesting  that  all  these  visions  shared  the  idea  that 
munitions  will  be  controlled  all  the  way  to  impact,  not  just  release. 

The  Navy  perspective  was  given  by  Edmund  Anderson 
(PEO  for  Navy  Strike  Weapons),  edmund.anderson@navy.mil  He 
related  a  vision  for  using  networked  fires  to  launch  (and  control)  an 
SM-6  /  Harpoon-3  to  the  limit  of  its  range,  not  just  to  the  limit  of  the 
ship’s  control  (effectively  doubling  the  range).  The  scenarios  he 
described  match  the  components  of  ours.  His  office  has  demos 
planned  for  ’09  and  ’10  ...  too  late  to  be  of  real  value  for  us. 
However,  he  does  have  a  program  office  that  is  interested  in  our 
conclusions. 

The  Air  Force  perspective  included  a  laydown  of  AFRL’s 
priorities 

The  Army  perspective  was  very  adamant  to  maintain  the 
person-in-the-loop.  Army  requirements  documents  will  continue  to 
force  decisions  made  by  humans  over  automation.  We  should 
keep  that  in  mind  for  our  efforts.  TLDHS,  AFATDS,  etc  will  remain 
a  centerpiece  of  the  Army  effort.  (The  Marine  Corps  briefs  later 
reinforce  this  link). 

Advanced  Technologies  for  Fire  Control 
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Most  of  the  briefings  in  this  section  of  the  symposium  were 
guided-sensor,  small-munition  combinations.  Many  of  the  weapons 
have  been  tested  on  some  scale  so  data  about  data  link  rates  etc. 
can  be  collected  although  we  probably  aren’t  going  to  do  any  big 
models  of  the  bandwidth  required. 

The  most  useful  project  information  from  this  section  is  from: 
Dr.  Piali  De  (Piali_De@raytheon.com)...  she  has  real  world 
experiment  data  for  CAS  and  artillery  support.  She  recently 
completed  an  exercise  with  the  Marine  Corps  where  all  fires 
requests/support  were  analyzed.  I’ll  get  a  copy  of  their  experiment 
results  and  her  briefing  slides.  These  are  something  we  should  all 
talk  about,  (file:  PDENFCS06  paper.pdf) 

Michelle  Adams  (Michelle. L.Adams@navv.min  ...  She  has  a 
number  of  very  valuable  pieces  of  information.  1 )  The  LANCE- 
NFCS  2005  demonstration  results.  This  is  an  AFATDS/NFCS 
multi-national  exercise.  In  particular,  they  used  a  common  XML 
message  to  do  all  the  targeting  information  -much  like  we  have 
talked  about.  2)  New  acronym:  JC3IEDM  -  The  Joint  Consultation 
Command  and  Control  Information  Exchange  Data  Model.  It’s 
common,  XML-based  and  part  of  a  very  large  data  standardization 
effort.  This  is  the  “9-line  streamlining”  effort  we  talked  about,  (file: 
FileControlSymposium_Brief.ppt) 

James  Matts  /  James  Cech  (cechjv@navsea.navy.mil)  - 
Naval  Integrated  Fire  Control  System.  More  NFCS  exercises  ... 
Useful  source  documents  for  how  the  Navy  intends  to  migrate 
NFCS.  Mr.  Cech  (an  NPS  grad)  also  made  a  pitch  to  ask  him  to 
come  out  to  be  a  guest  speaker.  I’ll  forward  his  information  to  Prof. 
Solitario. 

Chris  Shoaf  (Chris.shoaf@navv.mil)  NFCS  Joint  Test 
Threads  and  Architecture  documents. 

Combat  Identification  Session 

This  session  contained  multiple  briefings  regarding  various 
LADAR/LIDAR  sensor  programs. 

Joint  Air  and  Missile  Defense  Session 

Two  interesting  items  from  this  session. 

One,  a  Lockheed  presentation  took  a  different  tack  at  the 
coordination  problem  (a  different  way  to  look  at  networking). 

Two,  three  engineers  from  Raytheon  developed  an 
EXCELLENT  construct  to  move  from  the  requirements  views  to  the 
data  flows.  We’ll  have  to  show  you  on  slides,  it  would  take  too  long 
to  describe  here. 
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Network  Enhanced  Fire  Control  Session 


While  all  the  briefers  at  this  symposium  had  the  big  “Network  Ring” 
in  the  sky,  only  a  few  briefers  talked  about  what  made  it  up. 

Three  briefers  from  MIT  Lincoln  Labs  headed  by  Dr.  Steven 
Davidson  have  some  excellent  source  material  for  the  topic.  Mr. 
Roop  Ganguly  and  Jeff  McLamb  gave  briefings  on  what  would  be 
the  beginnings  of  a  requirements  analysis  for  the  network,  (files: 
Ganguly  -  AND  -  with  notes.pdf ,  McLamb  -  Early  Operator  -  with 
notes.pdf) 

We  spoke  at  length  with  Dr.  Davidson.  He  would  like  to  be 
involved  in  our  work  as  we  progress.  He  certainly  seemed  willing  to 
help  us  out. 

Also,  the  Marine  Corps  Roadmap  was  laid  out  by  Thomas 
Irwin.  We’ll  get  his  briefing  in  the  next  few  days  and  review  it  with 
our  group.  Bottom  line:  more  connectivity  with  AFATDS, 
abandoning  all  competing  programs.  God  Bless  the  Marine  Corps 
for  picking  a  single  service  direction  and  moving  toward  it. 
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The  Project  Team  held  a  stakeholder  input  session  in  Bullard 
Hall  in  August  of  2006.  The  purpose  of  the  meeting  was  to  collect 
stakeholder  needs  and  requirements,  as  well  as  receive  feedback 
on  the  group’s  work.  Some  of  the  relevant  questions/comments 
from  the  meeting  were: 

1.  How  are  you  defining  deconfliction?  The  deconfliction 
between  both  air  assets  and  ground  assets  was  addressed.  In 
addition,  the  deconfliction  between  field  artillery,  CAS,  and  other 
munitions  with  special  forces  was  addressed. 

(Earl  Richardson,  USMC/Capt/Infantry) 

2.  Recommend  Modeling  using  CBS  or  JCATS.  These 
systems  were  discussed  but  with  the  close  proximity  of  TRAC 
Monterey  it  was  decided  that  MANA  or  DAFS  would  be  the  best  for 
the  project  based  on  modeling  support. 

(MAJ  Chris  Wade,  BCTC,  FT  Leavenworth) 

Iraq  and  Afghanistan  is  a  slow  process  on  the  watch  floor  for 
Joint  Fires,  recommend  automation  of  process  as  much  as 
possible.  Discussion  on  the  need  to  automate  the  majority  of  the 
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process  was  held.  However,  the  need  for  the  man  in  the  loop  was 
discussed,  as  well.  The  concern  was  that  top  level  military 
personnel  would  want  a  person  to  give  final  authority  to  give  the 
feeling  of  human  control  of  release  authority. 

(MAJ  Tom  Stoner,  Army  Special  Forces) 

On  the  watch  floor  if  there  is  nothing  on  the  grid,  watch  floor 
personnel  want  to  bomb  it.  This  is  unacceptable  to  special  forces 
because  they  are  there,  but  they  will  not  show  up  on  grid. 
Therefore,  requires  a  Special  Forces  authorization  before  release 
authority  is  granted  for  Joint  Fires.  The  discussion  was  that  even 
though  we  have  a  good  idea  where  personnel  are  at  all  times  the 
special  forces  are  in  areas  that  are  only  understood  by  special 
forces  personnel.  Therefore,  they  must  be  present  and  must  give 
authority  prior  to  any  release  of  weapons.  In  addition,  the  JAG 
usually  has  a  cut  on  the  release  authorization. 

(MAJ  Tom  Stoner,  Army  Special  Forces) 

Will  the  system  of  systems  be  compatible  with  emerging 
Doctrine?  The  discussion  was  about  what  doctrine  is  provided  and 
how  it  compares  between  joint  doctrine  and  each  service  doctrine. 
It  was  determined  that  there  may  need  to  be  new  doctrine  written  to 
address  the  new  system  or  systems. 

(MAJ  Tom  Stoner,  Army  Special  Forces) 

Recommend  a  Joint  Fires  Operating  Center(s)  with  all 
services  in  control  of  launch  authority  in  a  central  location.  The 
discussion  was  that  all  fires  should  go  to  one  location.  This  would 
allow  for  all  service  authority  to  be  able  to  determine  the  need  or 
ability  to  provide  fires.  This  would  also  allow  for  optimization  of 
weapons  and  limit  fratricide  because  all  necessary  personnel  would 
be  available  for  consultation,  if  necessary.  This  includes  a  special 
forces  contingent. 

(MAJ  Tom  Stoner,  Army  Special  Forces) 

Battalion  Commander  won’t  want  the  company  commander 
making  the  decision  to  fire  in  case  a  new  company  is  approaching 
the  area.  The  discussion  was  about  the  ability  of  the  lowest  man  to 
have  authority  to  call  for  fires  and  the  ability  for  the  company 
commander  to  support.  This  led  to  the  ability  of  the  company 
commander  to  hold  the  big  picture.  If  he  can  see  the  same 
operating  picture  as  the  battalion  commander  and  he  is  trained  this 
may  or  may  not  be  an  issue. 

(Earl  Richardson,  USMC/CPT/infantry) 

All  of  these  personnel  were  experienced  in  either  the  Iraq 
and/or  Afghanistan  theaters.  Discussion  was  brought  forward  in 
each  of  these  areas  and  considered  in  the  approach  to  solving  the 
issues  with  Joint  Fire  Support  in  2020. 
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Joint  Fire  Support  in  2020  Advisors  &  Team 

Maj  Tyler  Gabriel 


The  SEA-10  Joint  Fires  trip  to  Fort  Irwin  and  Nellis  AFB  was 
informative  and  provided  us  with  a  perspective  of  the  fires  request 
process  that  we  hadn’t  seen  before.  The  coordination  process, 
especially  the  process  for  artillery  fires  as  it  exists  now,  was 
significantly  different,  operationally,  than  we  had  researched.  The 
coordination  and  insight  that  we  gleaned  from  our  interaction  with 
the  JFIIT  team  was  very  useful  determining  the  users,  providers, 
and  C2  stakeholders  in  our  proposed  system. 

FORT  IRWIN.  CA  -  National  Training  Center  (NTC) 

We  observed  the  JFIIT  team  was  involved  in  data  collection  in 
the  field  and  through  the  use  of  the  instrumented  range  equipment. 
The  JFIIT  team  had  between  20-30  folks  there  who  were  involved 
monitoring  every  part  of  the  exercise.  They  paired  each  of  us  up 
with  a  JFIIT  Observer  and  took  us  out  into  the  field  each  day.  Our 
team  took  turns  going  out  into  the  field  or  monitoring  the  exercise 
from  the  instrumentation  rooms  on  post  so  that  every  one  of  us  got 
to  see  the  exercise  from  both  perspectives.  The  scenario  at  NTC 
has  changed  dramatically  from  when  I  was  there  as  a  participant 
however,  and  the  pace  of  the  ‘action’  was  slow.  The  scenario  was 
a  ‘spin-up’  for  future  operations  in  Iraq  (SRO)  and  although  there 
was  opportunity  for  fire  support  requests  (almost  exclusively 
counter-fire),  they  were  few  and  the  coordination  process  was  not 
necessarily  doctrinal.  Additionally,  there  were  much  fewer  trained 
requesters  in  the  current  system  (about  six  per  brigade)  compared 
to  the  fully  netted  force  we  were  considering. 

The  units  in  the  field  suffered  from  pretty  severe  training  and 
manning  issues  that  hampered  both  their  actual  connectivity  and 
their  organizational  responsibilities.  In  conversations/interviews 
with  the  exercise  players,  the  biggest  issues  that  prevent  timely  fire 
support  are  the  coordination  process/oversight  and  deconfliction 
issues.  Hampering  their  ability  to  do  either  was  a  pretty  broad 
range  of  technical  competence... some  of  the  units  (Battalions)  had 
most  of  their  C2  systems  operating  (CPOF,  AFATDS,  etc)  but  many 
of  the  units  had  only  partial  connectivity.  It  appeared  that  the 
problems  were  mostly  training  issues,  but  the  systems  were  so 
diverse  that  there  was  a  high  training  requirement  for  each  of 
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them.  The  process  that  was  used  by  the  NTC  participants  to 
request  CAS  was  ad  hoc  and  didn’t  utilize  their  available 
resources... they  were  finally  able  to  find  a  surrogate  DD  Form  1972 
request  within  the  AFATDS  system  and  use  that  to  request 
support.  However,  there  was  no  feedback  from  “higher”  that  told 
the  requesting  unit  the  status  of  their  request.  In  conversations  with 
the  Air  Force  TACP  (JTACs)  in  the  field,  they  are  plagued  by  a  lack 
of  SA  on  the  status  of  requests.  Their  problem  wasn’t  in  making 
contact  with  higher,  but  with  getting  any  sort  of  feedback  on  what 
happened  to  their  request  after  it  was  sent.  As  a  result,  they 
adopted  a  ‘shotgun’  approach  to  requests  for  CAS... they’d  request 
through  several  avenues  and  with  repetition  and  hope  that  one  of 
the  requests  would  get  through.  From  our  perspective  back  at  the 
Division  TOC  and  notional  ASOC,  only  some  of  the  requests  were 
making  it  up  to  the  ASOC,  and  the  feedback  on  the  status  of  the 
requests  was  going  back  to  the  Brigade... the  info/SA  was  stuck 
there. 

Although  AFATDS  was  designed  to  be  a  system  of  record,  it  has 
MAJOR  loopholes  in  it  which  allow  users  to  bypass  the  automation 
features  that  are  designed  specifically  to  assist  them.  This  led  to 
ad  hoc  and  non-doctrinal  usage  of  all  aspects  of  the  current 
system.  I  especially  noticed  that  there  were  no  example  templates 
in  the  HELP  section  of  the  software. 

An  interesting  observation  was  that,  with  very  few  exceptions, 
the  communication  of  fire  support  requests  and  coordination  was 
almost  exclusively  done  via  voice  (radio  or  VoIP  phones).  Although 
systems  like  CPOF  are  built  to  maintain  a  COP  that  makes  the 
coordination  process  easier  and  faster,  the  technical  problems 
experienced  by  these  units  prevented  this  enabling  technology  from 
working. 

We  gathered  data  on  the  requests  for  CAS  and  the  timelines 
involved  with  each  request.  We  observed  the  equipment  currently 
in  use  and  the  portions  of  each  of  the  systems  that  are  actually 
being  used  and  the  portions  that  are  not  (either  due  to  difficulty, 
training,  or  connectivity).  We  also  had  a  discussion  with  LtCol  Ell 
(JFIIT  leader  at  NTC)  about  the  fire  support  process  and  he  offered 
his  insight  from  the  exercise  and  suggestions  for  our  project.  ASR 
(air  support  request)  data  for  NTC  is  posted  on  SharePoint. 

NELLIS  AFB.  NV  -  Air  Warrior.  Joint  T&E.  Red  Flag 

The  Project  Team  visited  the  AF  unit  that  supports  the  NTC 
exercises  with  CAS  assets  and  is  the  keeper  of  the  lessons  learned 
from  NTC’s  ground-air  interactions.  We  were  able  to  observe 
another  days  worth  of  air  support  via  the  instrumented  system.  We 
were  able  to  hear  the  conversations  between  the  JTAC  on  the 
ground  and  pilots  overhead  and  follow  their  discussions  of  targeting 
using  the  force  tracker  and  imagery  overlay.  In  team  meetings  with 
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the  Air  Warrior  staff  (LtCol  Barks  ad  Maj  Spechler)  we  discussed 
our  proposed  system  and  its  compatibility  with  the  CAS  process 
and  future  trends  in  CAS.  They  pointed  out  the  dangers  of 
coordinate  specific  weapons  (JDAM,  JSOW,  etc)  in  the  CAS  role 
and  said  that  at  least  90%  of  NTC’s  fratricide  incidents  (blue  air 
dropping  on  blue  forces)  are  due  to  these  types  of  weapons  being 
used  in  CAS.  They  also  told  us  that  the  responses  for  calls  for  CAS 
are  dependent  on  the  quality  of  the  request  and  the  information  in 
it.  We  attended  a  post-flight  debrief  of  a  CAS  engagement  and 
garnered  lessons  learned  from  the  coordination  and  deconfliction  of 
fires.  There  seemed  to  be  some  concern  about  overall  tasking 
authority,  especially  as  it  related  to  the  ASOC’s  ability  to  task.  The 
concern  wasn’t  whether  the  ASOC  had  the  authority  to  task  CAS 
assets,  but  instead  centered  on  the  quality  of  the  decisions  made 
by  this  tasking  authority.  As  it  applies  to  our  project,  the  take-away 
is  in  the  quality  of  the  tasking  and  whether  the  tasking  reflects  the 
ground  truth  about  what  is  really  going  on  in  the  AO.  In  our 
proposed  system,  there  seems  to  be  a  significant  need  for  a  man- 
in-the-loop  who  will  be  able  to  QC  the  tasking  orders  against  the 
latest  AO  update.  The  concern  for  us  is  to  design  a  system  that  is 
reliable,  or  more  to  the  point,  a  system  that  the  providers  trust  to 
give  them  the  best  tasking. 

We  visited  the  Joint  Test  and  Evaluation  program  for  Joint 
Fires  Coordination  Measures  as  well  and  discussed  the  Joint  Fires 
Area  concept  that  is  soon  to  be  released.  The  JFAs  are  3-D  areas 
that  are  intended  to  replace  “kill  boxes”  and  include  coordination 
and  authorization  for  fires.  The  T&E  program  is  about  2/3  complete 
and  they  discussed  and  provided  us  with  a  draft  version  of  their 
TTP  product.  They  had  some  interesting  insights  on  the  processing 
piece  of  the  coordination  that  we  can  take  into  our  conceptual 
model.  One  of  the  most  unique  points  for  me  was  a  discussion  of 
the  processing  of  requests... should  the  processing  be  focused  on 
the  “who  chooses”  or  on  the  “how  to  choose”  the  target-provider 
pairings? 

We  also  visited  the  Joint  Air  to  Ground  Operations  Group 
(JAGOG)  and  the  6*'^  Combat  Training  Squadron  to  discuss  the 
processing  of  requests  and  the  training  of  Joint  Tactical  Air 
Controllers  (JTACs)  and  Joint  Forward  Observers  (JFOs).  We  met 
with  LtCol  Ehmig  and  Maj  Oberdieck,  who  was  working  in  the 
ASOC  during  the  high-intensity  conflict  phase  of  OIF  and  he  shared 
some  really  interesting  insights  on  CAS  based  on  that  experience. 
In  collaboration  with  several  other  agencies,  they  are  developing 
JAGC2  (Joint  Air-Ground  Coordination  Cell)  concept  to  try  to  move 
towards  collaboration  instead  of  deconfliction.  This  concept  has 
some  interesting  implications  for  our  project... if  we  can  refine  our 
proposed  system  to  integrate  fires  smartly,  then  we  won’t  have  to 
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deconflict  the  fire  supporters  from  each  other.  We  discussed  in 
detail  the  current  systems  for  tracking  and  coordinating  fire  support 
requests,  especially  JADOCS,  and  we  now  have  a  working 
knowledge  of  how  JADOCS  is  used  in  theater  (and  Red  Flag 
exercises)  to  coordinate/deconflict  fires  from  targets. 

Overall,  this  multi-stop  trip  was  very  informative  and,  despite 
the  lower-than-expected  level  of  activity  at  NTC,  allowed  us  the 
opportunity  to  gather  some  valuable  data  and  discuss  aspects  of 
our  proposed  system  with  some  key  stakeholders. 
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APPENDIX  G. 


GENERATION  OF  ALTERNATIVE  ARCHITECTURES 


The  initial  steps  taken  to  generate  alternatives  were  built  upon  both  the  functional 
analysis  and  the  needs  analysis.  The  functional  analysis  was  analyzed  and 
several  areas  were  identified  for  assessment.  Among  these  functions  were:  send 
request,  process  request,  task  request,  and  send  tasking. 

Based  on  feedback  from  the  stakeholders  and  continuing  advances  in 
communications  capabilities,  three  possibilities  arose  for  sending  requests  and 
sending  tasking  orders:  they  could  continue  to  be  sent  via  voice,  they  could  be 
sent  as  a  digital  data  packet  via  a  point-to-point  transmission,  or  they  could  be 
sent  as  a  digital  data  packet  via  a  network  broadcast  transmission.  Each  of 
these  possibilities  has  advantages  and  disadvantages.  The  primary  advantage 
of  continuing  to  use  voice  requests  and  tasking  orders  is  in  the  simplicity  and 
ease  of  use.  Our  stakeholders,  especially  the  stakeholders  that  send  the 
requests,  identified  numerous  tactical  situations  that  would  favor  the  use  of  voice 
transmissions  over  data.  A  time-critical  situation  involving  friendly  troops 
engaged  with  the  enemy  in  close  proximity,  what  is  called  a  “Troops  In  Contact” 
(TIC)  situation,  would  tend  to  favor  a  simple  voice  transmission  over  a  data  entry 
task,  regardless  of  the  simplicity  of  the  data/request  entry  device.  The  added 
benefit  of  a  voice  transmission  is  the  ability  to  discern  contextual  messages  in  the 
voices  of  the  parties  involved.  The  strain,  panic,  or  stress  in  an  individual’s  voice 
can  relay  tremendous  non-verbal  information  to  another  human,  but  those  subtle 
messages  would  be  lost  by  any  sort  of  automated  translation  of  voice  to  data. 

The  digital  data  packet  method  holds  tremendous  promise  due  to  its 
relative  speed,  accuracy,  and  flexibility.  Unlike  a  voice  transmission,  a  data 
transmission  will  be  able  to  send  all  of  the  available  target  information  in  less 
than  a  second.  Additionally,  a  data  transmission  can  be  used  to  send  graphical 
data,  such  as  imagery,  as  well  as  text  data. 

The  transmission  method  of  these  data  packets  defines  the  other  two 
options  for  sending  requests.  A  digital  point-to-point,  similar  to  a  fax  transmission 
or  an  e-mail,  has  the  advantage  of  being  targeted  to  a  particular  recipient.  The 
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communication  procedure  for  this  type  of  transmission  dictates  that  positive 
feedback  is  required  from  the  recipient  that  a  transmission  was  received.  This 
trait  would  be  vital  to  a  system  where  “lost”  requests  have  life  or  death 
consequences.  Additionally,  a  point-to-point  transfer  system  would  not  suffer 
from  the  “information  overload”  of  a  system  where  numerous  broadcast-style 
messages  are  being  sent  to  everyone. 

On  the  other  hand,  a  network  broadcast  transmission  would  allow  for 
better  information  fusion  into  a  COP  if  the  system  was  able  to  organize  the  vast 
amounts  of  information  being  sent  at  any  one  time.  A  broadcast  transmission 
may  provide  advantages  in  provider  pairing  however  because  of  the 
transparency  of  the  target  information  to  all  interested  entities. 

The  processing  of  a  request  for  fire  was  conceived  in  several  different 
ways.  The  traditional  processing  method,  where  the  request  is  acknowledged  as 
“received”  and  then  tracked  throughout  the  remainder  of  the  pairing  and  tasking 
process,  was  one  alternative  for  this  function.  Another  option  was  to  “post”  the 
request  to  an  electronic  database  like  a  virtual  “bulletin  board.”  The  request 
processing  function  and  the  assignment  of  a  fire  support  provider  are  intertwined, 
but  the  methodology  options  to  determine  the  pairings  of  the  requests  with  the 
providers  is  a  unique  function  with  numerous  options.  Several  alternative 
concepts  were  conceived  for  the  pairing  motivations:  pairings  based  on  target 
type  and  predicted  effectiveness,  pairings  based  on  predicted  response  time, 
pairings  based  on  resource  efficiency,  pairings  based  on  organizations,  and 
pairings  based  on  a  combination  of  these  measures.  Any  determination  of  the 
“quality”  of  the  request  and  provider  pairings  would  have  to  be  made  in  the 
context  of  the  priority  scheme  applied  to  the  tasking.  Also,  the  pairings  should 
obviously  be  selected  between  possible  providers,  not  simply  the  available 
providers.  If  the  target  is  spatially  out  of  range  of  the  weapon,  then  that  weapon 
is  effectively  not  available.  Any  pairing  of  available  providers  would  also  need  to 
maintain  an  accurate,  up-to-date  database  or  list  of  providers  and  their  current 
status. 
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A  pairing  of  requests  with  providers  based  on  the  effectiveness  of 
provider’s  weapons  was  one  of  the  most  obvious  methods.  A  fire  support 
request,  regardless  of  format,  would  specify  to  some  degree  the  type  of  target 
and  the  effects  desired  on  the  target.  Based  on  that  target  information  and 
historical  weapons  effects  data,  such  as  the  Joint  Munitions  Effectiveness 
Manual  (JMEM),  the  expected  effectiveness  of  each  potential  provider  could  be 
assessed.  The  available  provider  with  the  greatest  potential  to  meet  the 
requested  target  effects  is  selected  and  tasked  to  service  that  request.  It  is 
important  to  note  that  the  selection  is  made  only  between  the  providers  that  are 
available  at  the  time  the  request  is  received  and  processed. 

Another  possible  pairing  doctrine  was  to  choose  the  provider  that  can 
service  the  request  the  soonest.  A  selection  in  this  method  would  have  to 
account  for  the  variations  in  tactics  across  the  diverse  weapon  system 
possibilities.  For  instance,  the  engagement  time  for  an  artillery  unit  ready  for 
tasking  is  on  the  order  of  a  few  minutes  from  tasking  to  weapon  impact  but  would 
be  substantially  longer  if  there  were  JFA  deconfliction  delays.  On  the  other  hand, 
CAS  aircraft  may  arrive  in  the  target  area  very  quickly,  but  the  pre-engagement 
coordination  and  deconfliction  would  surely  add  several  additional  minutes  before 
weapons  impact.  Assumptions  would  have  to  be  made  concerning  the 
responsiveness  of  a  potential  fire  support  provider  based  on  their  range  to  the 
target  and  their  reported  status.  These  assumptions  would  be  used  to  select  the 
most  responsive  fire  support  provider. 

From  the  perspective  of  the  JFC,  one  of  the  key  stakeholders  in  any 
proposed  JFS  system,  a  viable  pairing  methodology  would  be  one  that  optimized 
the  available  resources.  If  given  the  choice  between  using  provider  A’s  2  bombs 
or  provider  B’s  24  artillery  shells  to  produce  similar  desired  effects,  the  most 
efficient  provider  to  pair  with  that  request  would  be  A.  Each  weapon  system’s 
expendable  ordnance  could  be  assessed  for  availability  and  difficulty  to  re¬ 
supply,  and  that  data  would  be  used  to  select  between  available  providers. 

A  pairing  technique  that  aligned  requests  with  providers  based  on 
weapons  system  organization  or  type  is  in  widespread  use  today  by  those  that 
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request  the  fire  support.  One  of  the  two  possible  options  for  this  pairing  scheme 
involves  the  service  component  of  the  requesting  entity.  If  the  requester  is  Army, 
the  preferred  provider  might  be  Army,  followed  by  Air  Force,  the  Marines,  and  the 
Navy.  Another  possible  prioritization  option  could  be  based  entirely  on  the  target 
and  provider  weapon  system  type,  i.e.,  CAS  is  preferred  for  vehicle  targets  and 
artillery  is  preferred  for  troop  targets.  A  combination  of  these  two  priority 
schemes  is  another  option.  For  example,  if  the  requester  is  a  Marine  Corps 
TACP,  then  the  preferred  pairing  priority  might  be:  Marine  artillery.  Marine  CAS, 
Navy  CAS,  naval  surface  fires.  Air  Force  CAS,  Army  Artillery.  The  asset  paired 
to  that  request  would  be  selected  based  on  weapon  system  preference,  which 
may  or  may  not  be  a  surrogate  for  expected  weapon  performance  against  a 
particular  target. 

These  pairing  prioritizations  could  also  be  combined  in  various  fashions  to 
create  a  pairing  methodology  that  fuses  these  options.  This  appears  to  be  the 
method  preferred  by  the  existing  target  and  provider  decision  aides. 

Based  on  these  options  for  the  functions  of  our  proposed  system,  the 
Project  Team  combined  them  in  such  a  way  to  create  many  distinct  options  for 
the  conceptual  JFS  system,  five  of  which  were  considered  at  length.  Two  of  the 
five  alternatives  that  were  considered  were  determined  to  be  infeasible:  the 
“Status  Quo”  alternative  and  the  “Net-centric,  Man-portable  Joint  Fires” 
alternative. 

STATUS  QUO  ALTERNATIVE 

One  viable  alternative  is  to  do  nothing  and  keep  JFS  in  the  state  that  it  is 
in  now  (2006).  In  this  alternative,  the  predominant  method  of  sending  requests 
and  receiving  tasking  orders  is  via  voice,  not  data.  The  selection  of  the  best 
provider  for  the  target  is  completed  by  the  requester  with  little  to  no  knowledge  of 
what  is  available  beyond  the  resources  at  their  control.  The  pairing,  if  the 
request  is  routed  to  higher  headquarters,  is  made  without  a  complete 
understanding  of  which  assets  are  truly  available  and  not  just  on  the  ATO  or  the 


188 


map.  The  stakeholders  have  expressed  a  need  to  improve  the  system  for  JFS, 
therefore  maintaining  the  current  state  of  affairs  in  not  a  feasible  option. 

NET-CENTRIC,  MAN-PORTABLE  JOINT  FIRES  ALTERNATIVE 

In  this  alternative,  each  soldier  is  equipped  with  a  man  portable  weapon 
system  that  fulfills  his  fire  support  needs  and  minimizes  the  likelihood  that  he  will 
ever  have  to  request  external  fire  support  for  any  reason. 

Each  troop  carries  with  them  a  multi-purpose,  guided,  variable  yield 
weapon  system  that  obviates  the  need  for  traditional  heavy  fire  support  weapon 
systems.  Each  element  of  this  future  force  is  also  linked  wirelessly  to  all  of  the 
other  elements  in  the  theater  of  operations  and/or  in  the  battle  area.  These  links 
allow  for  remote  targeting  of  these  future  weapons  so  that  one  soldier/sensor  can 
call  on  the  weapons  of  many  other  troops  after  expending  his  weapon. 

A  key  enabler  to  this  concept  is  the  total  situational  awareness  of  the 
spatial  relationships  between  blue  forces,  non-combatants,  observed  red  forces, 
and  blue  weapons  and  their  associated  effects.  Pairing  of  joint  fire  support 
requests  would  be  accomplished  by  the  requester  using  a  simple  selection  based 
on  shortest  service  time. 

The  Project  Team’s  research  determined  that  the  technology  risks  to 
overcome  would  make  this  alternative  infeasible.  Even  the  most  optimistic 
predictions  of  weapon  technology  in  2020  do  not  meet  the  technical  requirements 
of  this  proposed  alternative. 

The  three  alternatives  that  were  analyzed  and  compared  were  the  Status 
Quo  Plus,  the  Centralized  Joint  Fire  Support  Network,  and  the  Distributed  Joint 
Fire  Support  Network.  These  are  discussed  in  detail  in  chapter  3  of  this  report. 
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APPENDIX  H. 


GENERATION  OF  NEEDED  JFS  SYSTEM  ATTRIBUTES 


A  functional  breakdown  of  a  Joint  Fires  system  was  accomplished  using  a 
dendritic  approach.  This  branching  led  to  the  development  of  system  metrics 
based  on  needs  defined  by  the  stakeholders  as  seen  below. 

1.  Function:  Coordination 

1.1.  How  many  organizations  are  involved  in  a  decision? 

1.1.1.  Improved  horizontal  and  vertical  integration 

1.1. 1.1.  Metric:  Count  process  gaps 

1.1. 1.2.  Metric:  Count  organizations  involved 

1 .2.  Does  the  system  provide  effective  decision  support? 

1.2.1.  Deconfliction  and  Pairing 

1.2. 1.1.  Metric:  Subjective  assessment 

1 .3.  Does  the  system  provide  clear  SA  to  the  decision  maker? 

1.3.1.  Improved  Situational  Awareness 

1.3. 1.1.  Metric:  Subjective  assessment 

1 .4.  Is  there  a  human  in  the  loop  at  the  right  place? 

1.4.1.  Reduce  risk  of  fratricide 

1.4. 1.1.  Metric:  Count  decision  points 

1 .5.  Do  all  component  commanders  have  access  to  the  same  information? 

1.5.1.  Reduce  C2  duplication 

1.5. 1.1.  Metric:  Count  of  systems  involved 

1 .6.  Does  the  system  streamline  operations? 

1.6.1.  Standardized  process 

1.6. 1.1.  Metric:  Subjective  assessment 

2.  Function:  Processing 

2.1.  Are  pairings  based  on  JFC  assets  or  service  specific  assets? 

2.1.1.  Effects  based 

2. 1.1.1.  Metric:  Pairing  efficiency  (model) 

2.1 .1 .2.  Metric:  Number  of  pairing  algorithms  available  to  CJTF 

2.2.  Does  the  system  reduce  overall  time  to  task  providers? 

2.2.1.  Improve  processing  rate  and  response  time 

2. 2. 1.1.  Metric:  Average  processing  time  (model) 

2.3.  Does  the  system  provide  robust  communications  architecture  to  the 
ground  element? 

2.3.1.  Request  methods 

2.3.1 .1 .  Metric:  Count  of  number  of  communications  paths  from  FO 
to  HQ  unit 

2.3.1 .2.  Metric:  Average  availability  of  each  communications  system 

2.4.  How  many  CFF  requests  types  are  required? 

2.4.1.  Common  training,  tactics,  procedures 

2.4. 1.1.  Metric:  Subjective  assessment 
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2.5.  Does  the  system  provide  correct  information  for  engagement  by  the 
tasked  weapon  system/provider? 

2.5.1.  Tasking  methods 

2.5.1 .1 .  Metric:  Number  of  compatible  weapon  control  system 
tasking  formats 

2.6.  Does  the  system  evaluate  target  priorities  according  to  commander’s 
intent? 

2.6.1.  Prioritization  methods 

2. 6. 1.1.  Metric:  Tailored  prioritization  algorithms  available  to  CJTF 

2.7.  Does  the  system  provide  air  and  ground  space  deconfliction  according  to 
commander’s  intent  and  current  operational  guidance? 

2.7.1.  Deconfliction  methods 

2.7.1 .1 .  Metric:  Tailored  deconfliction  algorithms  available  to  CJTF 

3.  Function:  Operationally  Feasible 

3.1.1s  the  system  scalable  through  a  wide  variety  of  future  scenarios? 

3.1.1.  Shift  from  organic  to  joint  support 

3. 1.1.1.  Metric:  Subjective  assessment 

3.2.  Does  the  system  provide  adequate  backup? 

3.2.1.  Redundancy 

3.2.1 .1 .  Metric:  Count  number  systems  involved 

3.2.1 .2.  Metric:  Count  number  of  communication  paths  available 

3.3.  Is  the  joint  fire  support  system  compatible  with  current  and  future 
(weapon/targeting/communication)  systems? 

3.3.1.  Interoperable 

3. 3. 1.1.  Metric:  Subjective  assessment 

3.3.1 .2.  Metric:  Number  of  open  architecture  interface  standards 

3.4.  Does  the  joint  fire  support  system  meet  the  operational  availability 
required  by  the  ground  forces  commander? 

3.4.1.  Availability 

3.4.1 .1 .  Metric:  Assessment  of  availability  of  physical  sub-systems 

3.5.  Are  the  human  to  machine  interfaces  user  friendly? 

3.5.1.  Usability 

3.5.1 .1 .  Metric:  Human  Factors  usability  study  of  physical  sub¬ 
systems 

3.6.  What  level  of  logistics  support  is  required  to  operate  the  joint  fire  support 
system  during  expected  operations? 

3.6.1.  Sustainable 

3.6.1 .1 .  Metric:  Logistics  analysis  of  physical  sub-systems 

3.7.  Does  the  joint  fire  support  system  provide  support  to  the  ground  forces 
commander  throughout  the  duration  of  the  operation/mission? 

3.7.1.  Reliable 

3.7.1 .1 .  Metric:  Reliability  analysis  of  physical  sub-systems 
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APPENDIX  I.  MODELING  OF  JFS  PROCESS  AND  COMMUNICATIONS 

The  following  pages  that  include  Tables  22  through  25  fully  outline  the  modeling 
results  described  in  the  Qualitative  Modeling  Section. 
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Marine  Generate  Request  1  x  x  x  Marine  Generate  Request  1  x  x  Marine  Generate  Request 

FSE  (CO)  Decision  1  1  x  x  x  x  FSCC/SACC  Decision,  Tasking  1  1  x  x  Decision  Aigorithm  Decision,  Tasking 

BN-REGT-BDE  Coordination  1  1  x  x  x  x  x  Providing  Ship  Tasking,  Engage,  Coordination  1  x  x  Providing  Ship  Tasking,  Engage,  Coordination 


Table  24:  Navy  Riverine  CFF  Request 
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Table  25:  High  Value  Target  CFF  Request 
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Average#  of  Steps  19.0  Average#  of  Steps  14.5  Average#  of  Steps  15.0 

Average#  of  Air  Gaps  8.5  Average#  of  Air  Gaps  3.0  Average#  of  Air  Gaps  3.0 

Average#  of  Process  Delays  16.0  Average#  of  Process  Delays  11.5  Average#  of  Process  Delays  12.0 

Average#  of  Systems  Needed  13.5  Average#  of  Systems  Needed  5.0  Average#  of  Systems  Needed  5.0 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 
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APPENDIX  J. 


EXTEND  MODELING  ORGANIZATIONAL  ALTERNATIVES 


Connectivity 

Perfect  connectivity  between  communication  systems  was  assumed.  All 
transmissions  were  received  but  delayed  by  a  random  distribution  with  the 
average  delay  based  on  historical  data  and  Project  Team  concurrence. 

Weapons 

Each  organization  had  some  fires  capability.  This  organic  capability  could 
be  mortars,  artillery,  missiles,  or  assigned  aircraft  (fixed  or  rotary).  Differentiation 
of  weapons  would  not  provide  additional  insight  at  this  level  of  abstraction. 
Therefore,  a  target  designated  for  brigade  engagement  was  engaged  by  the 
brigade,  without  distinguishing  between  an  artillery  battery  and  attack  helicopters. 

Target  Sets 

Targets  were  generated  to  arrive  randomly  and  assigned  to  the  correct 
provider.  A  limit  of  two  hundred  targets,  with  a  Poisson  arrival  process  (2 
minutes  average)  was  used  to  ensure  that  overall  processing  delays  were  not 
due  to  the  available  fire  provider  assets.  Targets  were  assigned  a  target  type 
based  on  a  notional  pairing  process.  The  system,  at  some  point  depending  on 
the  alternative,  would  match  a  provider  to  each  target.  Table  26  summarizes  the 
target-provider  pairing  ratios  and  the  provider  resource  limits  used  in  each 
simulation. 

Delays  for  pairing  and  deconfliction  are  based  on  alternative  systems,  and 
are  addressed  individually.  The  same  assets  are  available  and  transmission  time 
from  requester  to  next  organization  is  the  same  in  all  three  alternatives.  Total 
number  of  targets  was  limited  to  prevent  running  out  of  assets,  but  aircraft  were 
made  available  at  a  rate  of  2  per  every  40  minutes  to  simulate  close  air  support 
on  the  ATO.  Targets  assigned  to  aircraft  would  wait  “in  the  queue”  until  an  asset 
arrived  to  service  them. 
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Target  type 

Probability 

Provider 

Assets 

0 

50% 

Company 

60 

1 

20% 

Battalion 

120 

2 

15% 

Brigade 

96 

3 

7% 

Naval  Fires 

30 

4 

8% 

Close  Air  Support 

2/40  minutes 

Table  26:  Target  Probability  Distribution 


COMMON  COMPONENTS 

Fire  Support  Unit 

The  fire  support  unit  represented  an  asset  with  weapons  that  could 
provide  fires.  Each  unit  consisted  of  a  time  delay  to  process  the  request  and  task 
the  weapon  system;  and  an  engagement  delay.  Simultaneous  engagements 
were  allowed  based  on  multiple  units  or  provider  assets  at  this  level.  Figure  62 
shows  the  layout  of  the  fires  support  unit  process. 

Tasking  delay  (XDelayIn)  and  engagement  delay  (EngDelayIn)  were 
alternative  dependent  numbers  which  set  the  center  peak  of  the  distributions  in 
the  random  generator  blocks.  TaskingOut  was  used  to  capture  the  tasking  order 
generation  time  in  the  model  so  that  weapon  engagements  were  not  included  in 
the  overall  system  performance  comparisons. 


Figure  62:  EXTEND6""'  Fires  Support  Unit  Flow 
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Targets  were  generated  with  a  Poisson  process  with  a  mean  of  2  minutes 
as  shown  in  Figure  63.  Target  type  was  randomly  assigned  using  a  fixed 
distribution,  and  time  stamped  with  time  generated.  The  system  then  processed 
the  requests  depending  on  the  organization  of  each  alternative  and  forwards 
tasking  to  the  “catch  block”.  Total  time  delay  through  each  system  by  target  type 
was  output  for  analysis. 
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Target  Type 
CXjrrent  'Flrrie 
Reporting  Unit 


arrival  time  tgt  type 


Catch 


Tasking  Sent 


Figure  63:  EXTEND6™  Request  Input  -  Tasking  Output  Flow 


STATUS  QUO  PLUS 

The  Status  Quo  Plus  processing  structure  was  a  linear  process  based  on 
current  command  structure  and  was  connected  as  shown  in  Figure  64.  Requests 
are  received  at  the  company,  processed  to  determine  if  company  assets  can 
provide  support  and  were  either  tasked  or  forwarded  to  battalion  for  support.  The 
battalion  and  brigade  were  similar,  with  a  longer  delay  time  for  processing  the 
request.  Targets  not  engaged  by  the  brigade  were  forwarded  for  Air  or  Naval 
Fires  to  the  DASC,  ASOC,  or  Joint  Fires  Cell  for  final  tasking.  These  final  tasking 
processes  were  combined  in  the  simulation  by  assuming  similar  delays  and 
processing  capabilities  for  each  of  these  organizations 
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Figure  64:  Status  Quo  Plus  Flow  Diagram 


CENTRALIZED  JOINT  FIRE  SUPPORT  NETWORK 

The  centralized  processing  alternative  was  modeled  by  two  sequential 
delays  and  a  prioritization  queue  as  shown  in  Figure  65.  The  requests  were 
generated  and  placed  in  the  queue  on  the  left  until  they  were  transmitted  to  the 
Joint  Fires  Coordination  Cell.  The  reporting  delay  was  consistent  for  all  requests. 

At  the  Joint  Fires  Coordination  Cell,  requests  were  prioritized,  paired, 
deconflicted  and  authorized  for  tasking.  The  tasking  was  then  set  to  the 
appropriate  unit  for  engagement.  This  tasking  delay  time  was  estimated  at  5 
minutes  to  complete  with  12  simultaneous  requests  allowed.  Tasking  from  the 
headquarters  unit  to  the  provider  included  conversion  of  the  tasking  into  the 
appropriate  format  (MFCS,  AFATDS,  9-line,  etc.)  and  transmission  to  the  fires 
provider  is  contained  within  each  fire  support  unit  block  separately. 
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Figure  65:  Centralized  Process 


DISTRIBUTED  JOINT  FIRE  SUPPORT  NETWORK 


The  distributed  processing  alternative  was  modeled  by  two  sequential 
delays  and  a  prioritization  queue  as  shown  in  Figure  66.  The  requests  were 
generated  and  placed  in  the  queue  on  the  left  until  they  were  transmitted  to  the 
GIG.  The  reporting  delay  remained  the  same  for  all  requests. 

At  the  GIG,  requests  were  prioritized,  in  this  case  sorted  by  target  type, 
highest  number  first.  Concur  2  Shoot  represented  the  composite  delay  for  all 
potential  providers  to  receive  the  data,  bid  on  the  data,  concur  on  bids  and  finally 
task  the  applicable  unit.  The  tasking  was  then  set  to  the  appropriate  unit  for 
engagement  tasking,  conversion  delays  for  headquarters  to  provider  contained  in 
the  fires  support  unit  block  separately. 

The  pairing  delay  time  was  highly  dependent  on  quantity  of  participants 
and  bandwidth  availability  to  pass  the  various  messages  between  stations.  The 
Project  Team  agreed  on  a  3  minute  delay  by  assuming  that  brigade  and  senior 
headquarters  units  (or  equivalent)  were  nominating  their  assets  (including 
subordinate  commands)  to  reach  a  recommended  pairing.  To  push  to  fully 
decentralized  processing,  with  “every  soldier  a  sensor”  would  rapidly  increase  the 
quantity  of  messages.  It  was  deemed  ‘not  likely’  by  the  team  to  meet  a  three 
minute  delay  with  this  quantity  of  units  by  2020. 


Figure  66:  EXTEND6™  DJFSN  Processing 
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SUMMARY  OF  PROCESS  DELAYS 


Table  27  summarizes  the  average  delays  for  each  process.  The  listed 
distributions  were  used  and  the  specifics  are  discussed  in  the  Process  Delay 
Distributions  section. 


Status  Quo  + 

CJFSN 

DJFSN 

Distribution 

Initial  Call  for  fire  request 

0.5 

0.5 

0.5 

weibull 

Engagement  Times 

Company  Asset 

3 

3 

3 

lognormal 

Battalion  Asset 

3 

3 

3 

lognormal 

Brigade  Asset 

3 

3 

3 

lognormal 

Close  Air  Support 

10 

10 

10 

lognormal 

Naval  Fires 

10 

10 

10 

lognormal 

Process  and  Tasking  Times 

Company  Asset 

3 

5 

3 

weibull 

Battalion  Asset 

5 

5 

3 

weibull 

Brigade  Asset 

5 

5 

3 

weibull 

Close  Air  Support 

3 

5 

3 

weibull 

Naval  Fires 

3 

5 

3 

weibull 

ASOC/DASC/JOC 

5 

weibull 

Joint  Fires  Cell  decision 

5 

weibull 

GIG  collaborative  decision 

3 

weibull 

Table  27:  Summary  of  Simulation  Delays  (Minutes) 

ORGANIZATIONAL  ALTERNATIVES  SIMULATION  ANALYSIS 

Thirteen  runs  with  a  limit  of  200  targets  per  run  were  conducted  in  each 
EXTEND6™  model.  The  results  were  exported  to  Minitab  for  initial  analysis. 
The  models  show  statistically  significant  differences  in  expected  systems 
performance. 

Analysis  of  variance  (ANOVA,  general  linear  model)  evaluation  of  these 
results  was  conducted  with  a  null  hypothesis  that  all  systems  and  providers  were 
equal.  Summary  results  show  that  provider  (F  statistic=154,  p=0.0000)  and 
system  (F  statistic=391,  p=0.0000)  have  statistically  significant  differences  in 
response  time,  therefore  at  least  one  system  and  provider  was  different  from  the 
others.  The  main  effects  plot,  Figure  67,  graphically  represents  these 
differences.  Additionally  Figure  68  shows  the  organizational  time  performances. 
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Figure  67:  Main  Effects  Plot  for  Task  Delay 


Boxplot  of  task  delay  vs  S^tem 
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Figure  68:  Boxplot  of  Organizational  Time  Performance 
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ANOVA  comparison  of  the  data  assumes  normal  distributions  which  is 
not  the  case  for  the  simulation  results.  In  order  to  better  compare  the 
systems,  a  non-parametric  analysis  was  conducted.  The  Kruskal-Wallis 
results  are  show  in  Table  28. 


Kruskal-Wallis  Test  on  Delay 

System 

N  Median 

Ave  Rank 

Z 

CJFSN 

1753  8.873 

3045.1 

16.43 

DJFSN 

1701  5.696 

1673.0 

-30.53 

SQ+ 

1689  8.822 

2986.5 

14.00 

Overall 

5143 

2572.0 

H  =  933.16 

DF  =  2  P  =  0.000 

Table  28:  Test  on  Delay 


DJFSN  was  the  quickest  overall  system  as  evident  from  both  ANOVA 
and  Kruskal-Wallis  tests.  There  was  no  significant  difference  between 
CJFSN  and  Status  Quo  Plus  results  based  on  the  Kruskal-Wallis  test 
because  this  is  a  one-way  (single  variable)  test.  The  delay  effect  attributed  to 
provider  (target  type)  may  mask  the  potentially  significant  three  minute 
improvement  shown  in  the  main  effects  plot.  The  preponderance  of  company 
level  targets  may  unfairly  advantage  the  Status  Quo  Plus  system.  The 
assumption  that  a  permissive  fire  environment  with  the  company  having  the 
capability  to  self-deconflict  fires  on  roughly  half  the  targets  applies  to  a 
permissive  ROE  environment  and  not  a  cross  section  of  potential  future 
conflicts.  Figure  69  shows  the  distribution  of  times  by  system  and  target  type. 
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Boxplot  of  task  delay  vs  Alternative,  target 


Alternative  CJFSN  DJFSN  SQ+ 


Figure  69:  Tasking  Order  Processing  Delays 

Target  type  4,  which  required  an  air  asset  to  prosecute,  shows 
numerous  outliers  that  are  due  to  the  limited  number  of  providers.  With  no 
consideration  for  servicing  the  target  with  a  different  asset  within  the 
simulation,  these  requests  waited  in  the  queue  until  the  next  aircraft  showed 
up,  on  a  2  per  40  minute  cycle. 

The  box  plot  also  displays  a  fairly  consistent  median  response  time  for 
both  the  CJFSN  and  DJFSN  systems.  The  increasing  response  times  for 
status  quo  plus  was  expected  due  to  the  hierarchy  built  into  this  alternative. 
Comparing  the  CJFSN  and  Status  Quo  Plus  alternatives  shows  the  CJFSN 
appears  quicker  at  the  battalion  level  and  higher.  The  target  set  (50% 
company  level  targets)  assumption  is  masking  a  potentially  statistically 
significant  improvement  of  the  CJFSN  alternative  over  Status  Quo  Plus. 

Removal  of  all  company  level  targets  and  evaluating  the  simulation 
data  for  all  higher  echelon  commands  with  the  non-parametric  Kruskal-Wallis 
test  yields  the  results  in  Table  29. 
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Kruskal-Wallis  Test  on  Delay 


System 

N 

Median 

Ave  Rank 

Z 

CJFSN 

975 

8.786 

1358.7 

-2.12 

DJFSN 

921 

5.656 

694.9 

-32.38 

SQ+ 

909 

15.745 

2168.0 

34.64 

Overall 

2805 

1403.0 

H  =  1517.91  DF  =  2  P  =  0.000 

H  =  1517.91  DF  =  2  P  =  0.000  (adjusted  for  ties) _ 

Table  29:  Higher  Echelon  Non-Parametric  Results 

The  results  for  higher  echelon  providers  show  statistically  significant 
differences  in  all  three  alternatives.  The  centralized  system  is  slightly  better  than 
average,  while  the  decentralized  had  the  fastest  and  status  quo  plus  the  slowest 
time  to  process  a  request  and  task  a  provider.  This  implies  that  both  alternatives 
present  an  improvement  over  the  status  quo  plus  system  when  an  individual 
company  does  not  have  assets  or  authority  to  employ  offensive  fires  without 
involvement  of  higher  headquarters. 


SENSITIVITY  ANALYSIS 

In  order  to  examine  the  effects  of  the  various  distribution  means  on  the 
performance  of  each  system,  sensitivity  analysis  was  conducted.  Each 
parameter  was  systematically  varied  (individually)  and  overall  average  tasking 
times  were  calculated  for  30  runs.  The  results  are  tabulated  in  Table  30. 


Task  Time  (min) 

Status  Quo  + 

CJFSN 

DJFSN 

Baseline 

11.02 

9.83 

6.20 

Unlimited  Assets 

10.52 

9.33 

5.79 

Unlimited  Engagements 

10.87 

9.39 

6.04 

Double  CO  Decision 

12.62 

11.63 

7.27 

Double  BN  Decision 

12.34 

10.41 

6.80 

Double  BD  Decision 

11.78 

10.03 

6.38 

Double  JF/Concur/ASOC 

11.20 

14.07 

8.53 

Double  Report  Time 

11.82 

10.07 

6.62 

Target  Set  2 

12.28 

9.36 

5.90 

Table  30:  Sensitivity  Analysis  of  Tasking  Times 

Decision  times  were  individually  doubled  to  examine  the  impact  of  lower 
echelon  decision  times.  The  Joint  Operations  Cell,  GIG  process,  and 
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JOCC/ASOC/DASC  times  were  then  doubled  to  compare  impact  of  the  time 
required  for  higher  level  decision  processes.  Asset  quantities  were  set  to  10 
times  their  original  value  and  engagement  limitations  removed  to  assess  impact 
of  these  initial  assumptions.  Finally,  a  second  target  type  distribution  was  input 
into  each  model  to  compare  performance  of  each  alternative  against  fewer 
company  level  targets. 

Removing  limitations  on  assets  and  engagements  improved  all  systems, 
while  increasing  decision  times  degraded  all  systems.  The  only  parameter  that 
demonstrated  a  system  interaction  was  the  target  set.  Table  31 .  As  more  targets 
requiring  response  above  the  company  level  are  generated,  the  SQ  Plus  system 
performance  degraded  while  the  other  two  alternatives  remained  about  the 
same. 


Target  Set 

Provider 

1 

II 

Company 

50% 

30% 

Battalion 

20% 

30% 

Brigade 

15% 

25% 

Naval 

7% 

7% 

Air 

8% 

8% 

Table  31:  Target  Distributions 


Process  Delay  Distributions 

Random  number  generators  and  statistical  distribution  functions  were 
used  to  model  time  delays  for  each  of  the  alternatives.  Consistency  with  time 
delays  and  distributions  were  made  to  allow  a  comparison  of  the  alternative 
architectures. 

The  lognormal  distribution  was  used  to  model  engagements.  All  of  the 
results  are  positive  and  the  central  tendency  of  the  function  limits  the  number  of 
very  rapid  (near  zero)  engagements. 

Human-in-the-loop  decision  delays  were  modeled  by  Weibull  distributions. 
The  shaping  and  location  values  for  all  were  kept  the  same,  the  center  value 
changed  based  on  Project  Team  consensus  as  to  what  the  average  delay  should 
be.  There  is  a  greater  probability  of  a  very  quick  decision  being  made  using  this 
distribution  vice  a  lognormal.  During  routine  operations,  it  was  agreed  that  the 
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decision  makers  would  more  rapidly  assess,  assign,  or  concur  with  a  tactical  aid 
recommendation  thus  these  low  values  were  probable. 

Response  Time  Data 

Open  source  response  time  data  was  collected  from  several  sources  to 
baseline  inputs  for  the  various  models. 

Dr.  De  et  al.  reported  average  response  times  for  close  air  support 
depending  on  target  type  and  threat  density  about  from  5  to  10  minutes.  Artillery 
response  times  were  recorded  with  an  average  response  of  about  3.5  minutes, 
and  naval  gunfire  at  2  to  4  minutes.  “Digital  artillery,  mortar  and  naval  surface 
fires  missions  executed  twice  as  fast  as  air  missions.  This  is  because  all 
necessary  information  for  resource  management  is  readily  available  in  the  fully 
digital  artillery,  mortar  and  naval  surface  fires  missions.  In  the  air  missions,  two 
different  systems:  AFATDS  and  TBMCS  are  necessary  to  assign  an  aircraft  to  a 
mission.”®^ 

RAND  Corporation®®  references  15  minutes  as  a  typical  response  time  for 
aircraft  engagements,  with  significant  variability  based  on  CAS  employment 
(stack  vs.  deck  launched)  and  flight  times  based  on  geography.  Additionally, 
prosecuting  a  second  target  could  be  very  quick  for  an  attack  helicopter  “(b)ut  a 
bomber  employing  JDAM  usually  required  about  ten  minutes  between  drops  to 
enter  new  coordinates  and  to  reposition  itself,  a  considerable  time  when  friendly 
troops  were  under  fire”.®®  Their  modeling  used  15  minute  time  estimate  for  the 
prosecution  of  2  mobile  targets  with  a  section  of  aircraft.^® 


U.  S.  Marine  Corps,  Marine  Corps  Combat  Deveiopment,  “Marine  Corps  Fire  Mission 
Profiiing  Through  Experimentation  with  Reai  and  Simuiated  Systems,”  Raytheon,  2006,  pp.  15. 

Pirnie,  Vick,  Grissom,  Mueller,  Orletsky,  “Beyond  Close  Air  Support,”  RAND,  Santa  Monica 
CA,  2005,  p.  78. 

Ibid,  p.  88. 

Ibid,  p.  151. 
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Process  Delay  Times 


Generate  and  Send  Request  (All  Alternatives) 

Figure  70  depicts  the  default  reporting  delay  (30  sec)  added  to  all  targets. 
The  team  assumed  a  process  where  data  is  entered  (preferably  automatically) 
and  digitally  transmitted  to  the  next  higher  authority.  Occasionally  requests  may 
take  more  than  a  minute  to  send  due  to  transmission  delays  or  need  to  use  voice 
calls. 

Weibull(0.,  2..  0.5) 

?.oo 

1.00 

0.00 

0.00  0.20  0.40  0.60  0.80  1.0  1.2  1.4  1.6 

Figure  70:  Default  Reporting  Delay 


Army  Surface  Fires  Engagements  (All  Alternatives) 

Figure  71  depicts  the  engagement  process  that  was  modeled  for 
company,  battalion  and  brigade  assets  as  a  lognormal  distribution  (3  +-  0.6  min). 
The  time  does  not  count  against  the  tasking  message,  but  along  with  finite 
simultaneous  engagements  may  cause  the  target  queues  to  fill  up. 
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CAS  and  NSFS  Engagements  (All  Alternatives) 

Figure  72  depicts  the  Close  air  support  and  naval  fires  (both  gun  fire  and 
TLAM)  which  were  estimated  with  the  below  distribution.  The  distribution  (10  +- 
2  min)  may  be  optimistic  depending  on  asset  position  relative  to  target  and  actual 
unit  readiness.  Engagement  time  is  used  to  limit  simultaneous  engagements  and 
does  not  directly  add  to  the  tasking  time  of  the  fires  request.  Aircraft  were  not 
returned  to  a  ready  for  tasking  state  following  the  engagement,  but  naval  fires 
were. 

Lognormal{0.,  2.28, 0.198) 

0.25 


0.13 


0.00 

0.00  5.0  10.  15.  20. 

Figure  72:  CAS/NFCS  Engagement  Process  Delay 
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GIG-Enabled  Distributed  Processing 


Decision  Processes  (GIG  and  Ail  Lower  Echelon  Engage  Orders) 

After  much  discussion,  “near-perfect  connectivity”  of  brigade  and  higher 
echelon  commands  (basically  0-5/0-6  and  senior  commands)  was  evaluated  as 
a  reasonable  level  of  distributed  control.  Figure  73  depicts  that  with  the  quantity 
of  HQ  units  it  was  proposed  to  use  a  3  minute  delay  for  all  commands  to  concur 
on  a  provider-target  pair.  Addition  of  lower  echelon  commands  connected  to  the 
GIG  and  participating  in  a  distributed  pairing  process  would  drastically  increase 
the  amount  of  message  traffic  and  yield  a  significantly  higher  expected 
processing  delay.  Tasking  of  lower  echelon  commands  was  assumed  to  be  via  a 
local  digital  network  and  considered  as  part  of  the  3  minute  delay. 

Weibull(0.,2.,3.) 

0.30 
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0.00  2.0  4.0  e.O  8.0  10. 

Figure  73:  GIG  Lower  Echelon  Decision  Process  Delay 

CJFSN  Decision  Processing 

Centralized  Decision  Process  and  Lower-Echelon  Tasking 

Figure  74  depicts  that  the  centralized  Joint  Fires  Coordination  Cell  using 
pairing  algorithms  and  tactical  aides  was  determined  to  be  able  to  deconflict, 
pair,  authorize,  and  transmit  provider  tasking  in  about  5  minutes.  Lower  echelon 
commands  use  similar  processes  to  prioritize  and  translate  the  tasks  to  their 
organic  providers  with  the  same  time-delay  distribution. 
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Weibull(0.,2.,5.) 


O.m  2.t  4«  6.0  S.0  10.  10.  14.  16. 


Figure  74:  CJFSN  Lower  Echelon  Decision  Process  Delay 


Status  Quo  Plus  Processing 

Separate  delays  were  used  for  company  and  all  higher  echelon 
commands  in  the  status  quo  plus  alternative. 

Status  Quo  Plus  CO  Engagement  Decision 

Figure  75  illustrates  that  under  the  status  quo  plus,  requests  arrive  at  the 
company  for  processing.  With  limited  assets,  it  was  assumed  that  the  company 
would  decide  to  prosecute  or  forward  the  request  in  about  3  minutes.  Actual 
engagement  by  company  assets  follows  the  lognormal  distribution  described 
above. 

Weibull(0.,2.,3.) 
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Figure  75:  CJFSN  Lower  Echelon  Decision  Process  Delay 
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Engagement  Decision  for  BN/BDE  and  JOCC 

The  battalion,  brigade  and  Joint  Operations  Centers  were  assumed  to 
take  longer  than  the  company  to  decide  whether  assets  were  capable  or 
available  to  provide  support.  The  team  modeled  this  decision  process  at  about  5 
minutes  per  step.  Adding  the  engagement  delay  time  of  10  minutes  with  the 
above  lognormal  distribution  matches  historical  data  on  close  air  support  call-to- 
engage  times  of  about  15  minutes  referenced  in  Response  Time  Data  Section 
illustrated  in  Figure  76.  Naval  fires,  both  guns  and  Tomahawk  were  pooled  and 
given  the  same  average  delay  of  CAS  to  not  show  a  preference  for  response 
time  in  the  models. 

Weibull(0.,2.,5.) 
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Figure  76:  BN/BDE  Engagement  Decision  Process  Delay 
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APPENDIX  K. 


EXTEND  MODELING  OF  PAIRING  PROCESSES 


Common  Assumptions 

Calls  for  fire  were  modeled  as  discrete  events  with  three  attributes.  Target 
type  was  uniformly  distributed  from  0-9;  target  location  uniformly  distributed  in  the 
battlespace;  and  desired  effects  were  determined  (10%  harass;  15%  disrupt; 
50%  neutralize;  25%  destroy).  The  target  set  was  randomly  generated  then  fixed 
for  inject  into  the  three  models. 

Weapon  effectiveness  was  based  on  target  type  and  desired  effects.  It 
was  assumed  that  a  single  provider  was  tasked  and  the  effectiveness  applied  to 
the  target  was  tagged  as  another  attribute  on  the  request.  Effectiveness  was 
fixed  and  involved  a  table  lookup. 

Providers  were  represented  by  Army  Artillery,  USMC  Artillery,  AF  CAS, 
Navy-USMC  CAS,  and  Naval  Fires.  Effectiveness  of  similar  weapons  was 
identical. 

Model  Description 

Figure  77  represents  the  target  generation  and  pairing  algorithm.  Targets 
are  generated  from  the  program  block  on  the  left.  Target  type,  desired  effects, 
and  target  location  are  read  and  exported  to  an  excel  spreadsheet.  This 
spreadsheet  determines  the  notional  best  provider  from  all  that  can  strike  the 
target  based  on  location.  The  DE  equations  then  determine  which  provider  to 
task  based  on  a  resource  representing  the  provider  being  available  to  task.  The 
request  is  then  sent  to  the  applicable  engagement  section. 
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Figure  78  represents  an  engagement  block,  USMC  artillery  in  this  case. 
The  request  enters  the  engagement  queue,  target  type  and  desired  effects  are 
then  determined.  The  effectiveness  of  the  given  weapon  is  then  tagged  onto  the 
request,  representing  how  well  the  target  was  engaged.  The  resource  (artillery 
battery  for  example)  is  then  released  for  further  tasking. 


Following  the  engagement  section,  the  targets  are  combined  and  sent 
through  a  process  that  outputs  the  target  type,  provider,  desired  effects  and 
effectiveness  applied  to  an  excel  file  for  data  analysis,  as  shown  in  Figure  79 


Figure  79:  Data  Output  Section 


218 


Status  Quo  Plus 

The  status  quo  plus  system  prioritization  scheme  was  based  on 
preference  for  Army  artillery  fires,  followed  by  USAF  CAS  then  Navy  and  Marine 
Corps  assets  on  a  effectiveness  basis.  This  bias  towards  own-service  and 
existing  stove-pipes  resulted  in  a  lower  average  effectiveness  applied  to  the 
target  set. 

CJFSN  and  DJFSN  Joint  Asset  Pairing 

Both  Centralized  and  Distributed  Joint  Fire  Support  Networks  used  a 
pooling  of  all  available  assets  to  make  a  pairing  decision.  The  time  delays 
generated  from  the  communications  model  are  the  fundamental  difference  in  the 
models.  These  delays,  with  the  given  asset  availability  for  this  target  set, 
resulted  in  nearly  identical  results  for  the  two  systems. 

Optimal  Pairing  Solution 

To  determine  the  maximum  effectiveness  that  the  providers  could  apply  to 
the  given  target  set,  an  ‘optimal  pairing  solution’  was  designed.  This  system 
used  an  unlimited  quantity  of  providers  so  that  only  target  location  limited  the 
ability  to  task  the  best  asset  to  any  given  target.  Removing  the  location  limitation 
would  have  resulted  in  a  perfect  effectiveness  ratio,  with  every  target  being 
assigned  the  best  asset.  Figure  80  depicts  a  portion  of  the  Excel  spreadsheet 
used  to  process  and  prioritize  the  provider-pairings. 
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Figure  80:  Provider-Pairing  Process  and  Prioritization  Spreadsheet 
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MINITAB14™  Data  Analysis  Results 

The  resultant  data  was  imported  into  MINITAB14™  for  analysis.  Analysis 
of  variance  (ANOVA)  and  non-parametric  ranking  (Kruskal-Wallis)  methods  were 
used  for  data  reduction. 

Effectiveness  ratio  was  used  as  a  surrogate  for  weapons  effects.  It  was 
calculated  as  (effects  applied)  divided  by  (max  weapon  effects  available).  If  50% 
effects  was  the  maximum  available  (from  the  weapon  effects  table)  then  50% 
applied  =  1.0  effectiveness  and  25%  applied  =  0.5  effectiveness. 

Assumption  of  normality  is  suspect  as  shown  in  Figure  81,  the  normal 
probability  plot.  ANOVA  analysis  was  conducted  regardless  and  compared  to 
non-parametric  analysis.  The  null  hypothesis  for  all  analysis  is  that  there  is  no 
difference  between  alternative  systems,  providers,  or  targets. 


Normal  Probability  Plot  of  the  Residuals 

(response  is  Effect  ratio) 


Figure  81:  Normal  Probability  Plot 
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Figures  82  and  83  represent  ANOVA  results  which  show  that  at  least  one 
alternative  is  different  and  at  least  one  asset  (provider)  is  different. 


Interval  Plot  of  Effect  ratio  vs  Alternative 

95%  Cl  for  the  Mean 


Figure  82:  Mean  Effectiveness  Applied  by  Alternative 


Analysis  of  Variance  for  Effect  ratio,  using  Adjusted  SS  for  Tests 

Source 

DF 

Seq  SS 

Adj  SS  Adj  MS 

F  P 

Alternative  3 

47.0023 

18.5371  6.1790 

82.39  0.000 

Asset 

4 

9.3043 

9.3043  2.3261 

31.02  0.000 

Error 

3992 

299.3896 

299.3896  0.0750 

Total 

3999 

355.6962 

Figure  83: 

Effect  Ratio  ANOVA 

Figure  84  represents  the  overall  effectiveness  versus  the  Alternative  and  Asset 
represented  as  a  boxplot  which  shows  significant  overlap  of  results. 
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Figure  84:  Effect  Ration  vs.  Alternative  Boxplot 


Non  parametric  analysis  in  Figure  85  shows  the  optimal  solution  is 
significantly  better  than  the  proposed  alternatives.  The  optimal  solution 
represents  the  absolute  best  solution  possible.  The  difference  between  Status 
Quo  Plus  and  CJFSN  and  DJFSN  effectiveness  ratio  is  within  two  standard 
deviations  and  not  statistically  significant. 
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Kruskal-Wallis  Test:  Effect  ratio  versus  Alternative 

Kruskal-Wallis  Test  on  Effect  ratio 


Alternative 

N 

Median 

Ave  Rank 

Z 

CJFSN 

1000 

0.9039 

1735.9 

-8.37 

DJFSN 

1000 

0.9039 

1734.2 

-8.42 

Optimal 

1000 

1.0000 

2862.9 

27.27 

SQ+ 

1000 

0.7810 

1669.0 

-10.48 

Overall 

4000 

2000.5 

H  =  745.75  DF  =  3  P  =  0.000 
H  =  790.06  DF  =  3  P  =  0.000  (adjusted  for  ties) 

Figure  85:  Effect  Ratio  vs.  Alternative 


Conclusions 

Consideration  of  all  joint  fires  providers  available  to  prosecute  a  target 
improves  effects  applied  to  the  targets.  Using  actual  weapons  data  in  the 
effectiveness  table  could  yield  results  that  indicate  militarily  significant  differences 
in  the  proposed  systems.  Target  sets  for  a  variety  of  scenarios  could  then  be 
generated  to  examine  resource  requirements  to  achieve  desired  effects. 

An  algorithm  to  pair  available  assets  to  requests  for  fire  can  be  built  and 
meet  the  assumed  processing  time  (3  to  5  minutes)  used  in  the  communications 
model.  The  Extend-Excel  simulation  processed  1000  targets  in  under  3  minutes. 
Software  designed  for  this  processing  should  be  able  to  meet  or  exceed  this 
constraint. 
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APPENDIX  L. 


MANA  MODELING 


Building  the  Model 

The  Project  Team  built  a  model  using  MANA  (Map  Aware  Non-uniform 
Automata),  an  agent  based  model  to  define  agent  behaviors  and  states,  dictate 
topography,  routes,  and  weapons. 

The  Battlefield 

The  first  step  in  building  the  Urban  scenario  was  battlefield  layout.  Google 
Earth  provided  the  graphic  for  an  urban  area  (in  this  case,  downtown  Baghdad). 
It  is  important  to  note  the  vertical  and  lateral  limits  of  the  graphic  in  terms  of  units 
of  distance.  For  this  simulation  we  chose  a  10  mile  by  6.6  mile  area  of  Baghdad. 
This  directly  corresponded  to  battlefield  dimensions  of  1000  by  660  pixels  (units), 
yielding  a  pixel  distance  of  52.8  feet.  This  graphic  was  then  converted  to  an  8-bit 
bitmap.  This  format  is  required  by  MANA  to  distinguish  terrain  features,  each  of 
which  is  defined  by  a  RGB  (Red-Green-Blue)  value.  Each  color  thus  represents 
a  specific  terrain  feature,  and  each  terrain  feature  has  three  associated 
attributes;  Going  (ease  of  transit).  Cover  (terrain  which  will  block  incoming 
rounds)  and  Conceal  (terrain  which  acts  as  camouflage,  but  doesn’t  prevent 
agents  from  getting  shot).  After  the  picture  (.jpg)  is  converted  to  bitmap  (.bmp),  it 
is  then  touched  up  using  Microsoft  Paint.  Users  must  ensure  that  there  are  only 
the  desired  colors,  and  that  they  are  continuous.  If  there  is  a  break  in  color, 
agents  exhibit  unintended  manner. 

MANA  automatically  inserts  six  terrain  features  (Billiard  Table,  Wall, 
Hilltop,  Road,  Light  Brush  and  Heavy  Brush),  each  with  their  own  color.  The  user 
is  then  able  to  add  5  additional  terrain  features  and  define  their  3  attributes  (or 
delete  the  default  settings  and  define  11  user-specific  terrain  features).  For 
simplicity  and  expediency,  3  terrain  features  were  used;  Roads  (Going  1,  Cover 
0,  Concealment  0),  Heavy  Urban  (.3,  .5,  .5)  and  Light  Urban  (.6,  .3,  .3).  The 
graphics  for  the  battlefield  layout  and  terrain  map  are  shown  in  Figures  86  and 
87. 
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Figure  86:  Terrain  Map  (From^°) 


Figures?:  Terrain  Layout 


Google,  Google  Earth  ©  jpg  image,  [www.google. earth],  Oct  06, 
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Entities  (Agents) 

After  the  Battlefield  was  built,  the  principal  players  were  inserted  into  the 
simulation.  This  began  with  one  red  squad  of  a  single  agent  and  1  blue  squad  of 
a  single  agent.  Each  squad  has  properties  which  can  be  manipulated  to 
determine  agent  behavior.  The  Squad  Properties  menu  is  depicted  below  in 
Figure  88. 


Figure  88:  Squad  Properties  Menu  Window 

General  Control  Window 

The  General  window  allows  you  to  name  each  squad,  enter  the  number  of 
agents,  and  allocate  fuel  (not  used  for  this  simulation).  The  copy  squad  button  is 
the  most  useful  feature  of  the  simulation,  because  all  squad  properties 
(communications,  weapons,  ranges,  etc.)  are  transferred. 
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Map 


The  map  window  allows  the  user  to  determine  the  squad’s  starting  point 
(with  a  user-defined  region  of  uncertainty  so  that  each  time  the  simulation  is 
reset,  the  squad  starts  at  a  different  location).  As  shown  in  Figure  89  the 
waypoints  for  the  squad  to  transit  are  also  available.  Inserting  waypoints  is  as 
easy  as  a  left  mouse  click.  The  only  difficulty  in  selecting  waypoints  is  the  agents 
traverse  the  waypoints  in  reverse  order. 


Figure  89:  MANA  Map  Window 


Personality 

The  personality  window  is  what  gives  the  simulation  its  agent-based 
behavior.  As  shown  in  Figure  90,  this  screen  allows  the  user  to  give  each  agent 
relative  behaviors  for  Enemy  contact,  including  three  separate  enemy  threats  and 
an  “Ideal  Enemy”  (i.e.,  a  tank  for  a  Javelin  gunner).  Tendency  towards  the 
enemy  and  blue  forces  (either  injured  or  uninjured),  the  next  waypoint  in  series 
and  Cover  and  Concealment  are  included.  Variation  from  direct  routing  is 
adjusted  through  the  “Line  Center”  slide  bar. 
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Tendency  toward  enemy  engagement  can  be  adjusted  from  -100  to  +100, 
with  the  two  extremes  representing  complete  retreat  and  charging  the  enemy 
respectively.  Each  squad  has  a  threat  attribute  in  the  Range  window  which  is 
realized  upon  detection  (once  the  entity  is  detected  by  the  enemy,  the  enemy 
recognizes  what  threat  class  the  entity  represents).  This  allows  a  separate 
response  for  each  of  the  three  enemy  threats.  Also  included  are  adjustments  for 
tendencies  based  on  proximity  to  another  agent  (i.e.,  do  not  apply  this  attribute  to 
agents  within  XX  units  (Min  App),  or  apply  this  weighting  to  agents  within  YY 
units  (Max  Inf)).  The  cluster  option  prevents  agents  from  congregating  within  a 
small  area  by  applying  the  opposite  tendency  towards  aggregation  when  XX 
agents  are  present.  This  attribute  was  used  only  during  Enemy  Contact  states 
(discussed  later).  Situational  awareness  tendencies  were  not  used  in 
this  simulation. 


Figure  90:  MANA  Squad  Properties  Menu  Window 
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States 


Inherent  in  MANA  is  the  use  of  trigger  states.  Trigger  states  are  transitory 
states  of  a  user-specified  duration  that  elicit  a  specific  behavior.  As  shown  in 
Figure  91,  there  are  dozens  of  trigger  states,  and  separate  controls  for  each  of 
the  Personality,  Range  and  Weapons  windows.  Because  of  the  exponential 
increase  in  complexity  with  additional  trigger  states,  the  simulation  uses  two 
states:  the  default  state  for  patrolling,  and  the  Enemy  Contact  state  for  actual 
engagements  with  enemy  agents  (for  both  the  red  and  blue  forces).  Each  state 
allows  separate  settings,  which  may  lead  to  confusion  when  transiting  states. 
Care  must  be  taken  to  document  and  understand  state  changes  and  how  they 
affect  agent  behavior. 


Figure  91 :  MANA  Trigger  States  Menu  Window 

Ranges 

The  ranges  window  allows  the  user  to  select  the  agent  icon  for  each 
trigger  state.  This  is  useful  for  differentiating  which  state  the  agent  is  in  during  a 
simulation.  The  team’s  urban  scenario  used  a  patrolling  (Default)  and 
engagement  (Enemy  Contact)  icon.  Allegiance  is  either  White  (neutral).  Red 
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(Enemy)  or  Blue  (Friendly).  Only  red  and  blue  are  represented  in  our  simulation. 
Threat  classes  range  from  0  to  9999,  although  only  threat  classes  1  through  3 
are  available  for  specific  trigger  state  response.  Agent  class  is  used  to  determine 
order  of  engagement  for  enemy  forces  (i.e.,  target  priority).  Movement  speed  is 
based  on  a  per  time  unit  basis  (i.e.,  100/100  is  1  step  per  time  unit).  The  danger 
of  using  any  number  greater  than  100/100  is  agents  may  then  be  able  to  step 
through  walls  which  are  1  unit  thick  within  a  single  time  step.  Typical  foot  patrol 
speeds  of  up  to  six  miles  per  hour  yield  a  speed  of  between  one  half  (50/100) 
and  one  (100/100)  for  each  time  step.  Each  time  step  is  equivalent  to 
one  minute. 

Enemy  interaction  in  the  form  of  hits-to-kill,  %  concealment  per  turn  and 
Armor  are  included  as  well.  Percent  concealment  per  turn  represents  a 
cumulative  concealment  for  the  agent  on  a  time-step  basis.  In  other  words, 
50%  concealment  after  2  time  steps  is  the  equivalent  of  25%  concealment 
((1-.5)''2).  Armor  thickness  is  measured  in  millimeters.  Agents  were  given  either 
a  single  or  two  shot  hit-to-kill  based  upon  body  armor  and  support  (medical,  etc.). 
Neither  percent  concealment  nor  armor  attributes  were  used  in  the  simulation. 

Weapons 

Available  weapons  for  each  agent  include  kinetic  energy  and  indirect  fire 
weapons.  Also  included  are  options  for  agent,  squad  or  inorganic  situational 
awareness  cueing  (weapons  firing  using  outside  sensors).  As  shown  in  Figure 
92,  up  to  four  weapons  may  be  defined  for  use  in  each  trigger  state.  The  JFS 
simulation  used  only  weapon  1  and  a  single  trigger  state  (default).  Each  agent 
was  given  nearly  unlimited  ammunition  (10,000  rounds).  The  Range  to  Shooter 
(R)  table  allows  for  decreasing  P|<  with  increasing  range,  with  the  ability  to  linearly 
interpolate  between  two  values.  Soldier  agents  in  the  simulation  were 
guaranteed  a  hit  at  zero  range,  and  a  near-zero  probability  of  hit  at  1 ,000  yards 
(3,000  feet  or  60  distance  units).  Priority  order  and  non-target  classes  may  be 
entered  as  well.  The  remaining  settings  for  target  engagement  capability, 
penetration  and  threat  levels  were  not  used. 
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Figure  92:  MANA  Weapons  Window 

Squad  SA 

As  illustrated  in  Figure  93,  situational  awareness  for  the  squad  is 
composed  of  a  communications  delay  within  the  squad  and  contact  persistence. 
All  values  were  left  at  default  (0  and  30,  respectively). 


232 


Figure  93:  MANA  Squad  Situational  Awareness  (SA)  Window 

Inorganic  SA 

Extensive  use  was  made  of  the  Inorganic  SA  window.  Communication 
between  squads  is  entirely  controlled  by  the  matrix  of  allowed  communications 
shown  in  Figure  94.  Communication  implies  situational  awareness  to  the  extent 
that  contact  information  is  passed  over  the  communications  link  as  shown  above. 
Message  delivery  can  be  made  in  either  a  Fire-and-Forget  context,  or  in  the  case 
of  this  simulation,  an  acknowledged  receipt  (Guaranteed  Delivery).  Accuracy 
and  reliability,  as  well  as  parameters  for  latency  and  message  memory  can  be 
changed  to  suit  the  scenario. 
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Figure  94:  MANA  Squad  Communications  Window 

Algorithm 

The  algorithm  window  shown  in  Figure  95  was  left  at  default  settings  for 
the  simulation  (Stephen  Algorithm)  as  changing  the  algorithm  had  little  effect  on 
the  outcome  of  multiple  simulation  runs. 
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Figure  95:  MANA  Algorithm  Window 

Conclusion 

In  summary,  the  MANA  simulation  provided  the  project  with  a  means  to 
test  agent  behavior  in  a  specific,  controlled  environment  in  order  to  draw 
conclusions  about  the  efficacy  of  each  of  the  alternatives.  A  summary  of 
simulation  settings  is  shown  below  in  Table  32. 
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Table  32:  MANA  summary  of  simulation  settings 
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